Grupo 10 - Go4Surprise

En esta página se encuentra el feedback recogido por el equipo del grupo 10 durante las sesiones de clase. Con secciones para cada semana, se detallan los comentarios y sugerencias del profesor y los compañeros, así como las tareas a realizar para la siguiente semana. Además, se incluye una sección para cada grupo con el feedback proporcionado por el grupo 10.

Semana 1

Normas Generales

Asistencia: Obligatoria a todas las sesiones de evaluación. Commitment Agreement: Puede ser individual o en conjunto. Elegir las personas encargadas de solicitar el mando. Enviar un correo para remitir la solicitud a conserjería. Moderador: Elegir al moderador del grupo.

---

Grupo 7

Observaciones sobre la Aplicación La idea de la aplicación no está clara, se necesita más detalle. Competidores: Pokemon Go, Stride, Fog of World.

¿Se ha considerado algún otro tipo de pago además de la suscripción? ¿Los usuarios gratuitos pueden usar la aplicación o es solo para usuarios premium?

Innovación tecnológica: Uso de geolocalización. Roles: Ya están asignados.

Feedback Recibido: Poner el número del grupo en la presentación. Falta el logo al inicio de las transparencias. La plantilla debe transmitir valor, cuidar aspectos estéticos. Controlar el espacio en blanco y los elementos visuales. La idea de negocio debe ser clara desde el principio. Controlar la velocidad al hablar para mejorar la comprensión. La presentación debe ser un soporte para el mensaje. Definir correctamente el MVP y casos de uso core. Utilizar mockups para roles de usuario y cliente. Diferenciar entre equipos y roles de trabajo. Establecer claramente la cantidad de personas por rol.

---

Grupo 8

Aplicación: Aplicación de viajes en grupo con gestión de gastos. Cada persona dentro del viaje puede participar en la gestión. Implementación de todas las funciones en la app. Organización del Equipo: Uso de currículums internos para distribuir tareas. Todos deben desarrollar alguna parte del proyecto. Las tareas rotarán a lo largo de las semanas.

Funcionalidades Claves: Inclusión de fotos del viaje. Puntos de recuerdo y puntos de visita dentro de la organización del viaje.

Modelo de Ingresos: Aplicación gratuita con opción premium. Publicidad dirigida.Comisiones por afiliación. Venta de paquetes de experiencias personalizadas.

Objetivos en el Mercado: Amigos y familiares. Jóvenes y estudiantes. Turismo corporativo. Agencias de viajes y operadores turísticos.

Usuarios Piloto: Profesionales del sector turístico. Usuarios generales. Usuarios no familiarizados con medios digitales.

Feedback Recibido: Estética bien trabajada, plantilla bien elegida. Falta el logo y el nombre en la presentación. No se ha definido claramente el MVP. Se presentan demasiados casos de uso, es mejor enfocarse en lo esencial. Análisis DAFO: Mejor estructurar el orden de la presentación. Se recomienda leer el libro de modelos de negocio Business Model Canvas.

---

Grupo 9

Aplicación: App de aprendizaje interactivo basada en juegos. Personalización y competencia entre usuarios. Acceso a funciones premium como estadísticas.

Competidores: Duolingo. Preguntados. Brilliant. QuizUP. Modelo de Ingresos Aplicación gratuita con suscripción premium. Recompensas monetarias para creadores de contenido.

Normas y Compromisos: Sanciones: Falta de participación e incumplimientos de normas. Compromisos: Participación activa, dedicación de tiempo, comunicación, reuniones y puntualidad.

Feedback Recibido: El cambio de idea no fue bien recibido. Se sugiere volver a la idea de funerarias. No se ha mencionado Wuolah como competidor relevante. El nombre de la app es confuso. Definir mejor la restricción de público objetivo. Se debe aclarar el método de aprendizaje.

---

Grupo 10 (Nuestro Proyecto)

Feedback Recibido: Incluir la hora de regreso del descanso. Mejorar la organización del índice. Centrarse en los puntos más importantes debido al tiempo limitado.

El pago colaborativo ya está inventado. La idea de asumir el trabajo de los camareros no es bien vista. La propuesta debe ofrecer un valor diferencial frente a otros sistemas de pago.

Falta encontrar el caso de uso correcto. Se debe redefinir la idea para hacerla más realista y viable. El MVP debe reflejar mejor la propuesta de negocio.

La presentación ha sido llamativa, pero debe enfocarse más en la estrategia de clientes.

---

Grupo 11 (Feedback Recibido)

Feedback Recibido: La idea de "Tinder para universitarios" no convence. No hay suficiente mercado para justificar la aplicación. No aporta innovación relevante frente a otras redes sociales.

---

Para la próxima semana:

Definir mejor la idea de negocio, partiendo de lo general a lo específico.

Análisis riguroso de competidores con tabla comparativa.

Justificación de la selección de competidores.

Análisis de coste con un enfoque en TCO.

Definir usuarios piloto de manera más diversa.

Gestión de información aportada por usuarios piloto.

Refinar el MVP y definir casos de uso core.

Uso de mockups para visualizar la experiencia de usuario.

Clarificar roles del equipo y sus responsabilidades.

Elaborar un Commitment Agreement detallado.

Análisis preliminar de riesgos.

Evaluación de habilidades individuales y su aplicación al proyecto.

Semana 2

Grupo 7

Presentación:

• No hay referencias a presentaciones anteriores. Cada presentación debe ser autocontenida.

Competidores:

• El análisis no debe incluir información ilegible.
• No basta con pedir a ChatGPT que busque competidores; se debe justificar la metodología utilizada.

Modelo de Negocio:

• No se debe hablar del coste hasta que haya interés en el pago.
• El análisis de publicidad debe estar en la parte superior.
• Responder: ¿Por qué alguien pagaría por esto? ¿Cuáles son las características clave por las que pagará?

---

Grupo 8

Modelo Financiero:

• Los números no cuadran; deben tener claro su modelo financiero.
• Se mencionan gastos, pero no ingresos.

Competidores y Funcionalidades:

• Deben mejorar la definición de competidores, funcionalidades y modelo de negocio.

Mockups:

• Incluir ejemplos reales y detallados, no marcadores genéricos.

Costes y MVP:

• El análisis de costes debe estar argumentado: ¿por qué se han elegido esos valores?

Presentación:

• La información clave debe ir primero; se tardó mucho en llegar a la competencia.
• La presentación debe ser más estructurada y clara.

Aspectos Críticos:

• Privacidad: tratarse con seriedad.
• Innovación: no se ha mencionado la IA, riesgos o tecnologías.

Monetización:

• Explicar cómo se monetizará la contratación de profesionales.

Competencia:

• Se comparó con Manfred, que ofrece información valiosa sobre salarios y condiciones laborales.

---

Grupo 9

Idea y Enfoque:

• La idea tiene potencial, pero deben definir si el enfoque será serio o cómico.

Definición del Servicio:

• Se centraron demasiado en otros servicios en lugar de definir el suyo.

Mercado Objetivo:

• El público objetivo no es digitalizado, lo que supone un reto.

Marketing:

• Explorar estrategias de marketing agresivas.

Casos de Uso y Visualizaciones:

• Los UML no aportan suficiente valor; se recomienda usar mockups más dinámicos.

Competencia:

• Debe explicarse después de definir el negocio.

Modelo Canvas:

• No es legible.

Posicionamiento:

• Deben posicionarse al nivel de otros servicios funerarios.

Modelo de Ingresos:

• Considerar pagos recurrentes en lugar de un único pago post mortem.

---

Grupo 10 (Go4Surprise)

Modelo de Negocio:

• Existen fricciones en la percepción del precio.
• La gente busca la sensación de elegir sin generar estrés.
• Simplificar el concepto; considerar eliminar el factor sorpresa.

Mockups:

• Deben contar una historia, no limitarse a diseños técnicos.

Presentación:

• Es densa; se necesita más claridad.
• Evitar imágenes de fondo blanco sobre gris.

Logo:

• Colocarlo en la parte inferior en lugar de la esquina superior izquierda.

Tecnologías:

• Explicarlas según su aplicación, no como una lista genérica.

Costes (TCO):

• Expresarlo en meses y justificar los valores.
• Incluir costes de licencias y herramientas como GitHub.

---

Grupo 11

Idea:

• La idea ha mejorado, pero se ha invertido más tiempo en definir "lo que sois" frente a "lo que no sois".
• El concepto de "hotel para mascotas" se confunde con hoteles para personas que admiten mascotas. Se recomienda "Residencia para mascotas".

Modelo de Negocio:

• Falta definir bien el posicionamiento y los costes.
• No hay suficiente diferenciación con la competencia.

Presentación:

• Muy dirigida a preguntas y respuestas.
• Simplificar la información y centrarse en el modelo de negocio.

Mockups:

• Se dedicó poco tiempo; deben ser más elaborados.

Aspectos Visuales:

• La tipografía es pequeña y no se visualiza correctamente.
• La gráfica no se explica adecuadamente.

Datos y Justificación:

• El volumen de ventas parece aleatorio y no está justificado.
• Todo dato debe tener respaldo y ser explicado verbalmente.

Análisis de Riesgos:

• No debe ser una acumulación de documentos, sino estar estructurado.

Objetivos y Medios:

• Deben diferenciarse. Los medios no son penalizaciones.

Habilidades del Equipo:

• No se explicaron bien los costes de adquirir habilidades ni la selección de tecnologías.

---

Para la próxima semana:

Notas generales: El análisis de competidores es uno de los puntos más importantes y debe ser exhaustivo, explicando cómo se han identificado los competidores y justificando la metodología utilizada. La taxonomía de Bloom establece una pirámide de seis niveles, comenzando con el conocimiento, que implica saber que algo existe. Debemos ser capaces de tomar decisiones, ser creativos e ingeniosos, aplicando estos niveles en la estructura del proyecto.

En la presentación, lo más importante es dejar claro qué se vende y cuál es el problema que se va a resolver, ya que esto ayuda a captar mejor la atención del público. Es fundamental ser clave y directo. Se recomienda aprovechar toda la pantalla para los mockups, ocupando el máximo espacio posible y, si es necesario, dividir la información en dos diapositivas. Se han omitido secciones importantes como el commitment agreement y las reglas del grupo; estas deben aparecer de forma clara y no tratarse de manera indirecta. Todo debe quedar recogido de forma completa, especificando los objetivos y los medios.

En el commitment agreement se debe incluir una sección llamada "The Hall of Shame", donde se registre si alguien no ha cumplido con su responsabilidad y las correspondientes consecuencias. Se implementará un sistema de puntos semanal para evaluar a cada miembro, evitando que las cosas se den por sentadas. Es fundamental establecer un sistema claro de recompensas y penalizaciones para prevenir problemas futuros.

El análisis de riesgos debe abordarse con más detalle. Se sugiere extraer los riesgos directamente del DAFO para fomentar la interactividad. La presentación debe resaltar los puntos clave y tomar decisiones estratégicas para mitigar estos riesgos. La lista de riesgos no debe ser solo un inventario de problemas, sino una guía que indique las acciones para enfrentarlos.

En cuanto a la gestión del proyecto, según el PMOK, siempre debe haber un plan para cada área, incluyendo un plan de riesgos y de recursos. Estos planes deben ser accionables, con una sección específica dedicada al control de riesgos que muestre un enfoque diferencial en la planificación.

El TCO debe expresarse por meses y no por años, explicando de dónde provienen los datos y por qué se utilizan esos valores. Se deben incluir los costes de herramientas como GitHub y considerar que algunas licencias que se presumen gratuitas pueden no serlo.

El próximo día se realizará la evaluación, la cual es vinculante. Habrá dieciséis presentaciones, trece sesiones de feedback y un test. El control del tiempo será muy estricto: cada presentación debe durar exactamente dieciséis minutos. Quedarse corto o excederse en el tiempo se considerará un error igualmente grave. La asistencia es obligatoria y se detallarán las condiciones para suspender. Durante la clase se continuará con el feedback y, si no hay preguntas, se pedirá la intervención de forma aleatoria.

Para la próxima sesión, se espera un inicio impactante con un discurso de ascensor que capte la atención en los primeros diez segundos y exponga la idea de forma clara y directa. Se debe definir el tipo de negocio, realizar un análisis exhaustivo de competidores explicando el proceso de selección, y presentar un análisis preliminar de costes que contemple los costes personales, activos (como la amortización de materiales), indirectos, herramientas y licencias. La estrategia para involucrar a los usuarios piloto debe indicar cómo se integrarán en el grupo, los canales de comunicación, las fechas y los compromisos previstos. Por último, el MVP debe mostrar claramente los casos de uso core, apoyándose en mockups que cuenten una historia, incluyan botones e interacciones, y se centren en la experiencia del usuario.

Tareas para la próxima semana:

• Discurso de ascensores (Idea de negocio pero para los primeros 10 segundos)
• Tipo de negocio
• Análisis de competidores (Debemos indicar las razones y como hemos sacado los competidores)
• Análisis preliminar de costes
• Gestión de usuarios pilotos
• MVP (Casos de uso core, mockups con interacciones)
• Discusión sobre la innovación de negocio
• Stack tecnológico (conocimiento tecnológico del equipo de forma visual)
• Plan de gestión de riesgos
• Roles del equipo
• Commitment agreement
• Plan de gestión de calidad, gestión del pmbok, nivel de rendimiento
• herramientas obligatorias
• herramientas de libre elección, gestión de código
• landing page donde se explique la idea principal
• planificación de estimación para los siguientes sprints (sobre todo con mucho detalle el siguiente sprint, e 1)
• Informe del uso de la IA, indicando que se ha usado

Semana 3

Grupo 8

• Han sobrado 4 minutos.

• Han saltado directamente al MVP sin describir el producto.

• No diferencian entre MVP y producto.

• No explican la descripción del producto antes de presentar el MVP.

• El producto debe presentarse de forma ambiciosa con todas las características y luego enfatizar lo esencial.

• Mala estrategia de distribución de la información, no es digerible.

• No explican el origen ni la dedicación de los competidores.

• No se entiende la simbología (M.N, P.O…).

• Saltan directamente a los riesgos.

• Exceso de importancia a los números irrelevantes.

• Mala tipografía para el contenido.

• No se entiende si "beneficio" se refiere a ingresos o ganancias.

• No deben incluir IVA en los cálculos, es un valor transparente.

• No mencionan los precios de los planes.

• Cifras deben estar justificadas.

• La estructura de la información es confusa.

• No mencionar decimales innecesarios.

• No han comentado las tecnologías utilizadas.

• No revisaron si todo lo del listado de tareas está en la presentación.

• Falta el "Commit Agreement" y las herramientas obligatorias.

• PMV:

  • Recomendaciones de recetas personalizadas.
  • Detección de alergias o intolerancias mediante análisis.
  • Logros e hitos.
  • Marketplace.
  • Calendario con recordatorios inteligentes.
  • Foro de interacción.

• Competidores: Litle Lunches, Fuddle, Solid Starts, Nutria PP.

• Riesgos:

  • Técnicos: seguridad de información y privacidad, fiabilidad de datos.
  • Legales y regulatorios.
  • De negocio: retención de usuarios, competencia, baja adopción.
  • Operativos: mantenimiento, reputación, actualización de la base de datos.

• Beneficios:

  • Modelo Freemium.
  • Publicidad segmentada.
  • Marketplace.

• Infraestructura: Google Cloud, App Engine, Github, VSCode.

• Usuarios piloto: Padres primerizos, experimentados, premium, expertos en nutrición.

---

Grupo 7

• Fuentes de ingreso con número negativo.
• PMBOK es un marco de referencia, no una metodología.
• Problema con Web Socket: conexión debe gestionarse manualmente.
• Competidores: Stride Swarm, Mystery Hike, Fog of World, MapYourWorld.
• Funcionalidades core:
  • Mapa personal.
  • Exploración de zonas.
  • Registro de actividad.
• Preguntas clave:
  • ¿Cómo registran las zonas visitadas?
  • ¿Cómo dividen Google Maps en zonas?
  • ¿Tienen recompensas los usuarios piloto por feedback?
• Riesgos: Dependencia de API de terceros.

---

Grupo 9

• Competidores repetidos sin explicación clara.
• Salto de video a PowerPoint poco limpio.
• "Nube de competidores" mal presentada.
• Protopersonas: No aportan feedback real.
• Diseño:
  • Flechas en el Canvas atraviesan todo.
  • Fotos homogéneas para la presentación.
• Preguntas clave:
  • ¿Cómo seleccionan los usuarios piloto?
  • ¿Es rentable el modelo de negocio a ese precio?
  • ¿Se puede incluir videos en las esquelas digitales?

---

Grupo 10 (Feedback):

El plan de contingencia actual no está funcionando de manera efectiva. No estamos gestionando correctamente el riesgo, simplemente lo estamos reconociendo como un posible error sin tomar medidas preventivas adecuadas. Además, el tiempo disponible para abordar los gastos es muy limitado, y no estamos considerando las prácticas de otras empresas. Actualmente, estamos copiando a otras empresas sin adaptar sus modelos a nuestra realidad. Cualquiera de los eventos planificados no duraría ni un día, lo que resultaría en una gran pérdida económica. Este tipo de riesgos no favorecen el éxito de la empresa, ya que los riesgos altos y críticos parecen indicar que se enfrentarán problemas en el futuro, lo cual pone en peligro la viabilidad del proyecto.

Un modelo similar al nuestro es el de las tiendas de ropa, donde los clientes pueden probarse la ropa, pero si no la quieren, la devuelven. Asumimos todo el costo de las devoluciones y, al final, perdemos el negocio porque no cobramos ni nosotros ni las tiendas. Hemos dedicado demasiado tiempo y recursos a este riesgo, lo cual no está optimizando nuestro rendimiento. También es esencial que definamos claramente el alcance geográfico del proyecto. Es fundamental mencionar si el enfoque es nacional o mundial, ya que esto afecta significativamente a los números y a la planificación de la empresa.

Otro punto que necesitamos mejorar es la claridad de los números. A veces, las diapositivas están llenas de texto, y el número o la cifra se pierde entre tanta información. Los inversores quieren ver números, y necesitamos hacerlos visibles y claros, con menos texto y más foco en los datos clave. En cuanto a los riesgos operativos, si no tenemos suficientes unidades o alternativas disponibles, podríamos enfrentar dificultades. El MVP (Producto Mínimo Viable) también está llegando demasiado tarde, lo que significa que no está alineado con el proceso de planificación. Deberíamos haberlo definido antes de comenzar con el desarrollo. En resumen, hay que reorganizar todo, porque el proceso actual está desestructurado.

La estructura del índice debe ser fluida, evitando ser demasiado rígida. Las presentaciones deben seguir un hilo narrativo coherente, como contar una historia. En cuanto al coste por hora, es necesario especificar si es bruto o neto. También debemos incluir los costes sociales, que son muy importantes y no se están considerando correctamente. La Seguridad Social se lleva un 36% del sueldo bruto, lo cual debería estar reflejado en las proyecciones financieras. A menudo, en las presentaciones, se olvidan los costes variables, por lo que debemos ser claros y definir si los costes son por mes, semana o día. Además, es crucial entender el volumen necesario para mantener el proyecto a flote, es decir, cuánto necesitamos en términos de ventas y eventos para seguir avanzando.

Respecto a la cancelación de los planes, es importante aclarar cómo se gestionará. Si un cliente decide cancelar, no debe recibir el reembolso del dinero, lo que es una práctica común en muchos negocios. Tener muchos riesgos críticos es peligroso para la empresa, por lo que debemos gestionarlos de manera más eficiente. También es clave aclarar dónde será escalable el negocio geográficamente, ya que esto tiene un impacto directo en la proyección financiera y en el crecimiento del proyecto.

De nuevo, debemos tener cuidado con demasiada letra pequeña. Es fundamental que los números sean visibles y entendibles para todos, no solo los detalles pequeños. Respecto al MVP, necesitamos que esté listo mucho antes de que nos enfoquemos en los riesgos. Debemos contar primero qué vamos a hacer al principio y luego abordar cómo mitigaremos los posibles riesgos. Es necesario que todo esté alineado y que la presentación se convierta en una historia clara para el público.

Finalmente, en cuanto a los costes sociales y los sueldos, no podemos olvidar el 30% adicional de los costes de Seguridad Social. Es importante mostrar estos valores con claridad, además de explicar si los costes se consideran por mes, semana o día, y cómo impactan en el volumen de negocio necesario para que el proyecto avance.

Resumen:

• Plan de contingencia no resuelve los riesgos.
• Riesgos críticos hacen parecer el proyecto inviable.
• No consideran costes sociales ni impuestos.
• Escalabilidad:
  • Definir si el proyecto es local, nacional o internacional.
  • Evaluar qué sucede si no hay eventos en ciertas ubicaciones.
• Presentación:
  • Fluidez en la narrativa.
  • MVP debe presentarse antes que los riesgos.
  • Demasiado texto, mejorar el enfoque visual.
• Costes y Finanzas:
  • Especificar si son costes brutos o netos.
  • Incluir costes sociales (~30-36% del bruto).
  • Definir si los costes son mensuales, semanales, por unidad de tiempo.
  • Estimar volumen de clientes necesario para sostenibilidad.

---

Grupo 11 (Feedback)

• Diferenciar entre hoteles pet-friendly y residencias para mascotas.
• Letra de la tabla de competidores muy pequeña.
• No incluyen número de página.
• Stack tecnológico:
  • Bien descrito, con diagrama UML.
  • Separar bien frontend de cliente/navegador.
• Costes:
  • Ingresos estimados basados en reservas (500-1000).
  • Reservas de contingencia.
• Preguntas clave:
  • ¿Solo aceptan perros?
  • ¿Qué proceso de selección usan para usuarios piloto?
  • No mencionaron la matriz DAFO.
  • ¿Aceptan otras mascotas grandes (caballos, etc.)?

---

Indicaciones para la Próxima Semana

• Implementación de Sprint 1 con enfoque más técnico.
• Evaluación de desempeño individual basada en productividad.
• Elementos clave para la presentación:
  • Killer opener (claro y conciso).
  • Elevator Pitch.
  • Análisis de competidores (tabla).
  • Análisis de costes.
  • Definición de roles en el Sprint.
  • Seguimiento del "Commit Agreement".
  • Prototipo actual del software.
  • Retrospectiva: qué fue bien/mal y qué mejorar.
  • Análisis de rendimiento del equipo.
• Cuantificación de métricas de productividad individual.
  • Respuesta en tiempo a mensajes.
  • Número de commits y contribuciones en GitHub.
  • Análisis de rendimiento basado en datos.
• Política de versionado: asegurarse de que cada versión esté correctamente documentada y congelada en los despliegues.

Semana 4

Grupo 10

Actualmente, no estamos trabajando bien y están surgiendo problemas, no solo en el desarrollo del software, sino también en la presentación. Se han abandonado elementos clave en comparación con la presentación anterior. Un aspecto fundamental es el inicio efectivo, donde se explica el proyecto y se capta la atención de la audiencia. Hasta ahora, no se ha logrado ese impacto inicial, y esto es crucial. Aunque no se haya pedido explícitamente, es un punto muy importante que debe estar listo para la próxima semana.

Para generar ese impacto, se necesita un elevator pitch sólido, acompañado de un killer opening, una frase breve y llamativa que enganche desde el principio. En este punto del proyecto, no se puede seguir presentando sin esa introducción fuerte. Para alguien que ve la presentación por primera vez, después del inicio debe venir una explicación clara de por qué nosotros y un análisis de la competencia. No es necesario incluir un índice; la información debe estar organizada de manera fluida.

Tras abordar los puntos débiles, la siguiente sección clave es la parte económica, donde se presentan los ingresos, los gastos y cómo se proyectan las cifras. Este enfoque debe seguir la estructura típica de las presentaciones para inversores, respondiendo a sus inquietudes. Es fundamental anticipar las dudas sobre la viabilidad del negocio y demostrar que hay una oportunidad real. Todo esto debe explicarse en tres minutos, sin extenderse demasiado en los costos.

Otro aspecto esencial es el equipo detrás del proyecto. Se debe destacar la experiencia de los fundadores y el equipo, transmitiendo confianza en la capacidad de ejecución. Esta primera parte se cierra con un bloque enfocado en ventas y en la explicación clara del problema, para que el público comprenda su importancia. Es importante notar que la parte técnica de informática no interviene en esta sección.

A partir de aquí, la presentación pierde estructura. Un ejemplo de esto es la mención de los usuarios piloto, que en la presentación actual se introduce demasiado tarde. No basta con decir que tenemos usuarios piloto, sino que debemos explicar cómo los estamos gestionando, cómo interactuamos con ellos, cuánto tiempo damos para recibir feedback y cómo organizamos esa información. Además, debemos seguir buscando más usuarios piloto, ya sean amigos, vecinos o contactos interesados, para mejorar el producto con más retroalimentación real.

Otro error es la inclusión de los riesgos, ya que no forman parte esencial de la presentación en este momento. En lugar de listar riesgos, hay que centrarse en los problemas actuales y en las acciones de mitigación que se han implementado. Es clave medir la evolución y revisar si los resultados actuales coinciden con lo que se esperaba anteriormente. Este análisis debe abrir un debate sobre lo que se ha hecho hasta ahora y los ajustes que han surgido en el proceso.

En la retrospectiva, no basta con mencionar los problemas; también hay que detallar cómo se han gestionado. No se trata de destacar solo la actitud del equipo, sino de analizar cómo el compromiso y la seriedad con el proyecto afectan su desarrollo. Si no se toman acciones concretas, podemos encontrarnos con problemas mayores. En este sentido, el Commitment Agreement es una extensión del plan de riesgos y debe presentarse de manera seria. Antes de enviarlo, debe exponerse en clase para su evaluación.

En cuanto a los horarios y la desviación en la planificación, si hay justificantes válidos deben ser mencionados; de lo contrario, es un aspecto que se debe corregir. Es necesario mostrar un enfoque más profesional en todos los aspectos del trabajo.

Respecto al desarrollo, se ha señalado que no tiene sentido haber comenzado por el inicio de sesión. Hay ejemplos claros, como Amazon, donde no es necesario registrarse para comprar. Un inicio de sesión no es un caso de uso central en este momento, y hay alternativas más eficientes. Actualmente, ni siquiera hay zonas privadas en la plataforma, por lo que la autenticación no debería haber sido una prioridad. Se debe reconsiderar cómo se estructuran las funciones clave, de la misma manera que en un videojuego primero se diseña la experiencia de juego antes de centrarse en el menú.

Otro punto débil es la landing page, que presenta problemas de diseño. La fuente del texto es demasiado pequeña y no se visualiza bien. Es necesario hacer cambios estéticos para mejorar su legibilidad y presentación. Además, debe contener datos reales que refuercen su credibilidad.

En general, la estructura de la presentación no está bien organizada. Es urgente reorganizar los contenidos, priorizando lo esencial y asegurando que el mensaje sea claro, impactante y estructurado de manera lógica.

Grupo 11

Cosas positivas: Habéis abordado bien los puntos clave, y el guion ahora es mucho más fácil de seguir. Sin embargo, se ha notado que el número de páginas no es visible, lo cual puede ser un detalle importante para la presentación. Además, no tenemos un "Hall of Shame", lo que es positivo en cuanto a la transparencia.

Respecto a los servicios extras, se mencionan características que tienen otras empresas pero que no ofrecemos, lo cual genera confusión sobre por qué se incluyen en la presentación. En cambio, sería más efectivo destacar lo que nosotros ofrecemos y cómo se diferencia. Por otro lado, en la retropectiva, a partir de ahora no es necesario enfocarse tanto en lo que se ha hecho, sino en los problemas que hemos enfrentado y cómo los hemos solucionado. A los evaluadores les interesa más el progreso realizado, cómo avanzamos en el proyecto y el cumplimiento del total del sprint. La evolución del trabajo debe ser visualmente representada para que se vea claramente si estamos avanzando al ritmo esperado, por ejemplo, si la aguja va por el 50%, está bien. Esto se puede hacer mediante un gráfico visual, que es lo que se está pidiendo, y debería integrarse en la presentación de la semana que viene.

Visualización del progreso: Todo lo que se explique con imágenes mejorará el esfuerzo de lectura y reducirá el estrés visual de los evaluadores. Es importante que todo el equipo vea cómo se va desarrollando el trabajo de manera tangible y con gráficos claros. El rendimiento también es clave, no solo en términos de horas trabajadas o commits realizados, sino evaluando si el esfuerzo es justo para todos los roles involucrados (código, documentación, etc.). Además, se debe analizar si es razonable pedir respuestas rápidas a los miembros del equipo, ya que esto puede afectar su productividad real. El número de líneas de código no es una métrica viable, ya que en ocasiones un número negativo puede indicar baja calidad. Debemos centrarnos en ver cómo mejoramos tras la refactorización o a través de un microdespliegue. Lo importante es que la métrica sea positiva o, en su defecto, esté cerca de cero.

Métricas justas: Es necesario tener en cuenta las métricas de manera más racional, como el porcentaje de tareas completadas, pero también es importante que se premien tareas de mayor calidad y no solo tareas pequeñas. Hay que definir límites racionales para las horas a invertir y jugar con la desviación en las métricas de manera individual. Es incómodo, pero usar estas herramientas ayudará a medir la productividad real de cada miembro del equipo. Por ejemplo, penalizar a alguien pero luego darle una puntuación alta sin justificación no tiene sentido. Hay que asegurarse de que la correlación entre esfuerzo y resultados esté clara. Los métodos de puntuación deben ser individuales para que reflejen de manera justa el trabajo de cada uno.

Retrospectiva: En cuanto a la retropectiva, no debe enfocarse en decir solo lo que se ha hecho, como las reuniones o el trabajo rutinario, sino más bien en los problemas encontrados y cómo los hemos resuelto. Se quiere ver cómo vamos completando el sprint, con un seguimiento visible del progreso. Es crucial mostrar la evolución de cada tarea. La aproximación al rendimiento ha sido buena, pero se debe evaluar si es justo para todos los roles.

Usuarios piloto: Respecto a los usuarios piloto, se necesita una agenda más concreta. Aunque el plan de comunicación está bien estructurado, debe incluir fechas y tiempos específicos. Además, se deben evitar los anglicismos innecesarios, como "Configura el CI", que pueden resultar confusos.

Métricas a mejorar: Las métricas deben incluir:

• Tiempo de trabajo total.
• Tiempo de respuesta.
• Número de correcciones en QA.
• Número de tareas completadas, siendo más específico en este punto según el volumen de cada tarea.
• Cumplimiento del plazo de entrega.

También es fundamental tener en cuenta los retrasos en lugar de solo el número total de tareas completadas. Los retrasos pueden ser indicativos de problemas en la planificación o ejecución, y deben ser evaluados para mejorar el proceso.

Grupo 7

Reflexiones sobre las presentaciones: En el primer grupo pensaban que no habían presentado el guion la semana pasada, pero en el segundo grupo sí. A pesar de que estuvieron más cerca de lo esperado, aún quedan elementos de presentaciones anteriores, lo que ha restado tiempo. Además, se permitió agregar información adicional que no era relevante y que ocupó tiempo innecesario. Como ejemplo, el DAFO y el Model Canvas que, aunque importantes, no son necesarios en esta etapa y ocuparon espacio innecesario.

Gestión de riesgos y problemas a mitad del sprint: Es importante hablar de los problemas y la gestión del riesgo, mencionando si se ha introducido algún nuevo riesgo o si alguno de los riesgos previamente identificados se ha visto materializado. Deberíamos haber dejado más tiempo para lo que realmente era fundamental en esta semana. En lugar de introducir tantos detalles, es necesario centrarse en lo que realmente toca ahora, como explicar el problema desde el inicio de forma clara. Es crucial mantener una línea argumental coherente para que la presentación no pierda foco. A medida que avanzamos, la presentación debe convertirse en algo más técnico y organizativo, dos elementos claves que debemos mantener hasta el final del tercer sprint.

Encuestas y feedback de los usuarios piloto: En cuanto a los usuarios piloto, los resultados de las encuestas apuntan a la necesidad de un plan de gestión claro. Ya se ha trabajado sobre los mockups en función de este feedback, y lo que se debe destacar en la presentación es lo mínimamente indispensable que los usuarios pidieron. Algunas personas han mencionado hasta tres puntos menos que otros compañeros, lo que refleja que todos deben cumplir con un mínimo común. El core de la presentación debe estar alineado para todos, siguiendo una línea argumental clara.

Presentación visual y de contenido: Es importante actualizar y no utilizar elementos que ya están obsoletos, como el Canvas, ya que ahora estamos en una fase de desarrollo y no corresponde mostrarlo. Las fuentes de ingresos pueden seguir siendo parte de la presentación, pero deben ser presentadas de forma más clara, ya que hay muchas otras fuentes que podrían entrar en juego. Los subtítulos son mejor valorados que los llaves; estas últimas quitan mucho espacio y no facilitan la comprensión. En vez de usar símbolos o ecuaciones complicadas, es más eficaz organizar la información en tablas, para facilitar la digestión del contenido.

Alineación y legibilidad: Algunas de las diapositivas tienen demasiados detalles, como la diapositiva 27, que es imposible de leer debido a la sobrecarga de información. Se debe agrupar la información y alinearla correctamente a la derecha para mejorar la comprensión. Costes de personal y otros detalles como cuánto cobra cada rol son menos relevantes en esta etapa, por lo que es mejor no incluirlos si no hay tiempo para digerirlos. Se ha notado una mezcla de español e inglés en la presentación, lo cual puede resultar confuso, por lo que todo debe estar en español y evitar el uso de anglicismos innecesarios.

Confusión entre problemas y riesgos: Una confusión que se ha observado es la mezcla de problemas y riesgos en las tablas. Los problemas deben diferenciarse claramente de los riesgos previstos. Cuando algo no estaba planificado y surge un problema, debe ser tratado como tal, y no mezclado con los riesgos. Además, se necesita una mejor gestión del tiempo en las reuniones: si se planean reuniones de dos horas, pero se extienden a cuatro, se está afectando el progreso. Hay que establecer cómo se alcanza el 100% de las tareas y cómo se resuelven los problemas que surgen.

Soluciones a los problemas: Si un problema surge y se tiene una solución, se debe explicar cómo se solucionó y cómo se aplicó la acción de mitigación del riesgo. Si el plan no ha funcionado, es importante explicar por qué no ha funcionado en lugar de presentar una solución nueva sin análisis. Además, es crucial evitar demasiado texto y muchas tablas, ya que estas sobrecargan la presentación y no permiten que el público siga fácilmente el flujo de la información.

Progreso del proyecto y presentación visual: Es fundamental incluir el porcentaje de avance del proyecto, en lugar de usar simplemente tildes. El uso de colores como el naranja no es adecuado, ya que no es fácil de entender si se ha avanzado mucho o poco. Si se utiliza un porcentaje, debe quedar claro si el 34% representa el trabajo completado hasta ahora o si es el progreso de todo el sprint. Además, se ha observado que la landing page debe estar siempre presente y ser accesible, ya que es algo permanente en la presentación.

Grupo 8

Usuarios Piloto y Recopilación de Información: Los padres no son una fuente confiable de información real para este tipo de proyecto. Están proporcionando información falsa o de otro contexto, lo que no es útil para obtener insights precisos. Se debe buscar a usuarios reales del producto, no recurrir a fuentes fáciles como los padres. Los usuarios piloto deben ser más activos, no solo dar respuestas pasivas. Este cambio es importante para obtener resultados válidos.

Mejoras en la Presentación: Hoy se ha mejorado en la organización, el contenido se acerca más al guion. Es crucial no recuperar elementos de presentaciones pasadas (como el Model Canvas) ya que no deben ser reemplazados o agregados nuevamente si no están alineados con la etapa actual del proyecto. Si algo no estaba antes, debe quedarse fuera. La documentación adjunta es la que debe cubrir los elementos que no se presentan en las diapositivas.

Stack Tecnológico: El stack tecnológico debió haberse mencionado la semana pasada, pero no se incluyó. Esta información no debe estar oculta o tardar en aparecer. Presentarlo de manera clara y comprensible facilitará la digestión de la información.

Costes y Organización de la Información: Los detalles sobre los costes deben ser organizados mejor. El desglose de costes de personal no es tan relevante. La presentación debe ser más clara y concisa, como el uso de tablas que permitan ver de forma rápida la información, y solo un subtotal de los costes totales, sin mostrar detalles innecesarios. Es importante que se indique el coste de herramientas, ya que parece ser mayor al del personal debido a la falta de decimales o puntos en la cifra. El 11,18% residual tiene importancia y debe destacarse.

Amortización de Equipos: No están amortizando los equipos correctamente, lo cual es importante, ya que de lo contrario, Hacienda podría considerarlo un gasto inadecuado. Se debe cuidar cómo se presenta esta parte.

Gráficos y Visualización: Para facilitar la comprensión, los costes por usuario y el coste de adquisición de usuario deberían presentarse con gráficos en lugar de texto y números extensos. Los gráficos son más fáciles de entender, y poner un porcentaje visualmente (como un 7%) facilita que la audiencia se quede con la idea clara de qué significa la conversión.

Presentación Visual y Ritmo: Es importante que la presentación mantenga un ritmo adecuado. Si se olvida algo, seguramente no es relevante para la presentación. Deben filtrarse los detalles no necesarios. Lo más importante debe estar al principio, no al final, para que el público se enfoque en los puntos clave. No se debe abrumar con demasiado contenido, especialmente con tablas y detalles como los CPI y otros cálculos.

Planificación y Diagrama de Gantt: El diagrama de Gantt y los detalles de planificación no son visibles ni fáciles de comprender en la presentación. Deben resumirse y mostrar solo los avances más relevantes en 2 o 3 barras, con lo más importante, para que sea más comprensible.

Empatía y Comunicación: En el inicio efectivo de la presentación, faltó empatía hacia los niños y el contexto infantil. El tono debe ser más emocional y cercano, no en tercera persona, para lograr una conexión con la audiencia. La pasión al presentar es fundamental para que el mensaje llegue de manera efectiva.

Deducción y Claridad de los Costes: La forma de mostrar los costes debe ser clara y fácil de procesar. Los decimales y puntos son esenciales para que los números sean correctos. En relación al hardware, debe quedar claro si el coste total de los equipos está siendo amortizado correctamente o si esto podría tener implicaciones fiscales. La reducción de la carga conceptual es clave para que la audiencia no se sienta abrumada con demasiada información. Mostrar el coste de adquisición de usuario en un gráfico es más efectivo que solo mostrar los números en texto.

Planificación y Métricas: La planificación debe ser más visible y fácil de seguir. La presentación actual no resalta cuáles son los avances, ni qué se ha logrado. Los conceptos como CV, SV, etc. deben ser explicados de manera más clara para que el público entienda de dónde vienen estos términos y cómo se aplican al proyecto. La tabla de arriba también debe explicarse adecuadamente para evitar confusión.

Grupo 9

Los costes son muy bajos, excesivamente bajos. Solo asumen esta parte inicial, luego, ¿qué? El soporte, atención al cliente… Hay servicios que tienen que montar encima. El tiempo es lo que les falta. Los costes, ingresos y gastos deben presentarse de forma que se pueda ver la evolución del proyecto. ¿Cuánta gente está en edad de morirse y pueda pagar eso? En la edad en la que nos preocupamos por estas cosas es cuando hay descendencia, por lo que hay que ser más conservadores en los cálculos, utilizando cifras normales. El tema de los gastos no es realista, ya que se cambian versiones, debe migrar, hay agujeros de seguridad… Siempre se debe mantener actualizado el software.

¿Cuánto tardas en llegar a ese 1%? Se suele utilizar canales de forma inteligente. Si las floristerías tienen un negocio normal, a lo mejor se deberían de aliar con ellas. Tú lo encargas, una corona, algo muy típico. Utilizas un canal a un coste muy bajo. A la hora de la presentación, no se ha contado lo que hacen antes de hablar de la competencia. Dicen el ámbito en el que trabajan, pero deberían comenzar explicando qué producto y valor van a ofrecer antes de mencionar la competencia. ¿Qué otras opciones existen? Este es un punto de mejora clave en el discurso inicial.

Se utiliza el tema de la venta para crear un clima al inicio y normalizarlo, pero si no, es imposible. Si hablamos de la muerte, ¿es demasiado pesimista? Es importante trabajar el entorno en toda esa parte inicial. La principal fricción que suele ocurrir con los seguros es que sale más caro cuanto más tarde en morirse la persona. Es raro que el servicio cueste. Si cobran una cuota constante, deben ofrecer un servicio constante para que la gente aprecie el valor. Es importante que esa parte se trabaje adecuadamente.

Se puede pensar en el modelo de un solo pago. Si la empresa se muere antes que yo, ¿qué pasa? Eso deben tenerlo en cuenta. Es bueno trabajar todos los segmentos del mercado. Las cosas cambian, y los memes también. Pueden hacer algo para ver qué está de moda hoy día y qué está desfasado. En cuanto a los impuestos, no deben incluirse, ya que todo es antes de los impuestos. En este caso, no se trabaja con el IVA, lo cual lo pagan los consumidores. Deben incluir los costes sociales de los empleados. Existen técnicas para no pagar impuestos, como reinvertir, pero eso no se comenta.

Solo se deben mostrar los datos en bruto, con el personal, que es lo más fundamental. Falta añadir el factor tiempo, que es crucial. El tiempo y el dinero son elementos clave. Si pueden duplicar dinero, pero no se dice cuánto tiempo tardan en hacerlo, eso es negativo. ¿Cuánto tiempo para pasar de 100 a 200? Es importante para la inversión. Deben saber cuándo. El tiempo es fundamental. Todos los aspectos relacionados con el dinero están directamente ligados al tiempo.

Siguen pagando los costes sociales, especialmente los primeros 15 días, y los restantes… Pagan la nómina por los primeros tres meses. Si alguien se pone enfermo y tiene justificación, deben asumirlo como equipo y no trabajar más. Las vacaciones sí, pero si alguien se enferma más de lo esperado, eso debe ser revisado.

En cuanto a cómo han conseguido los usuarios piloto, los han conseguido a través de amigos, padres, familiares… Si comienzan con 15 y cada uno encuentra 3 o 4 personas, ya pueden llegar a 50, teniendo en cuenta a los de su clase. Con 2 o 3 usuarios por persona, ya es un número significativo. No deben conformarse con lo que tienen, sino buscar siempre más.

Indicaciones para la Próxima Semana

En la introducción, es fundamental transmitir el modelo de negocio de manera clara y concisa. La idea debe explicarse en un minuto utilizando un killer opener y un elevator pitch efectivo. Esto permitirá captar la atención desde el inicio y dejar una impresión clara de la propuesta.

El análisis de competencia debe centrarse en lo esencial. Es clave responder a preguntas como qué hacemos, en qué mercado nos movemos y qué problema resolvemos. Además, hay que destacar con precisión qué nos diferencia de la competencia para que quede claro nuestro valor añadido.

En cuanto al TCO (Total Cost of Ownership), este debe presentarse de forma realista y detallada, incluyendo los costos de capital (CAPEX) y los costos operativos (OPEX). La información financiera debe ser lo más limpia y clara posible, evitando confusión en la interpretación de los números.

Para la situación actual y proyecciones financieras, se deben estimar ingresos y gastos a corto y medio plazo. En la semana 0 solo hay gastos, por lo que estos deben presentarse en la parte inferior de la gráfica, mientras que los ingresos estarán en la parte superior. A medida que pasa el tiempo, los ingresos deben ir aumentando y los gastos disminuyendo. Se recomienda representar estos datos con una curva de evolución, mostrando distintos escenarios: optimista, pesimista y realista. Es fundamental destacar que las primeras 15 semanas son cruciales, ya que el comportamiento financiero cambia en el largo plazo.

La sección del equipo debe ser breve y colocarse al inicio de la presentación. Se debe mencionar únicamente a los integrantes clave sin entrar en detalles técnicos, ya que el foco principal es el negocio y no el perfil técnico de cada miembro.

Para la DEMO del prototipo, es crucial presentar un producto funcional con los casos de uso clave bien definidos. Debe ser una demostración realista y creíble, donde el usuario pueda ver el valor del producto de manera inmediata. Se recomienda contar con un video grabado que resuma la funcionalidad, ya que la presentación es lo más importante y debe captar la atención antes de revisar documentación técnica o detalles del despliegue.

El análisis de rendimiento del equipo debe reflejar la calidad del trabajo, los resultados obtenidos y los problemas enfrentados durante el sprint. Es importante comunicar que, al inicio, el progreso puede ser más lento, pero luego se puede recuperar. Durante el desarrollo, se debe mantener cierta flexibilidad, pero el cierre del sprint es el aspecto más crítico. La presentación debe incluir un resumen detallado de todo lo que ha ocurrido en el Sprint 1.

En cuanto al reloj de avance, se debe mostrar claramente lo invertido y el total, sin recurrir a diagramas de Gantt poco visuales. La evolución del proyecto debe ser clara y comprensible, con gráficos que permitan ver el progreso de manera intuitiva.

Respecto a los usuarios piloto, no solo es importante hacer un seguimiento del plan, sino también demostrar el avance logrado. Se debe presentar un registro de los usuarios que se han comprometido a participar y evaluar su efectividad. Es recomendable contar con un sistema de control para saber quiénes han entregado resultados y, en caso necesario, enviar recordatorios. En la presentación, se debe incluir solo la información clave, mientras que la documentación detallada se revisará por separado.

Para el Sprint 2, es fundamental definir las responsabilidades al inicio y al final del sprint. Además, se debe ofrecer una estimación global del resto del proyecto, más allá del segundo sprint, para tener una visión clara del camino a seguir.

El informe de uso de IA debe reflejar la transparencia en su implementación. Como parte de esto, se recomienda incluir una diapositiva final con la URL corta de la landing page, para que los interesados puedan acceder fácilmente a más información.

Por último, es esencial mantener un equilibrio en los tiempos de la presentación. Cada sección debe recibir la atención adecuada sin extenderse innecesariamente, garantizando una exposición clara, efectiva y bien distribuida.

Resumen

• Intro: 20% de 15 minutos, y tiene que estar en esta intro:
  • Modelo de negocio, es decir, transmitir la idea de negocio con inicio efectivo, elevator pitch y killer opener (1 minuto),
  • Análisis de competidores más rápido e ir a la clave,
  • TCO realista y detallada en el que distingamos el CAPEX y OPEX ,
  • Cuál es la situación actual,
  • Estimación de ingresos (tienen que estar justificados y que se vea de manera sencilla y clara) y gastos a corto y medio plazo
  • Equipo (bastante corto)
• Demo Sprint 1: 15%
  • Desplegado con los casos de uso core de la app, tiene que ser probable y ver resultados (video(con una url no hace falta ponerlo en la diapositiva) o en directo)
• Retrospectiva completa del sprint: 40/50%
  • Rendimiento del equipo
  • Resultados
  • Cómo hemos medido
  • Problemas encontrados
• Gestión y todo lo de usuarios pilotos 10%
  • Numero de usuarios
  • Lo que nos han dado este sprint estos usuarios
  • Plan del sprint 2 con estos usuarios
• Planificación, como que vamos a hacer en el sprint 2 15%
  • Estimación concreta con asignación de responsabilidades con objetivo para la mitad y final del sprint
  • Estimación global del resto de sprint
• Uso informe de la IA
• Landing page (QR y url)

Semana 5

Grupo 11

Observaciones Generales

El "killer opener" actual no es lo suficientemente atractivo; parece más un anuncio para inversores que una estrategia efectiva para captar la atención de la audiencia. Se recomienda utilizar un enfoque más llamativo que genere interés desde el principio. Una vez que se logre esto, las transiciones entre secciones serán mucho más fluidas y naturales.

En la parte de apertura, la gráfica que muestra los usuarios proyectados para 2025 presenta un año incompleto. Se sugiere omitir este año o prorrogarlo para evitar confusiones. Además, la escala de la gráfica no es clara y puede llevar a malentendidos. Es importante recordar que los costes son altos al inicio, ya que no hay ingresos, y a partir de ese momento, al lanzar el producto, los costes seguirán variando. Inicialmente, los costes son elevados y luego disminuyen a medida que el producto se ajusta a las necesidades de los usuarios.

El coste inicial debe estar claramente vinculado al desarrollo del MVP. Se deben utilizar términos precisos y apropiados. Normalmente, se utilizan gráficos de barras y un gráfico consolidado; en este caso, la presentación no logra hacer una distinción clara mediante el uso de colores y justificaciones en la misma gráfica. Además, se debe aclarar el embudo de conversión, especificando qué porcentaje de usuarios se convierte en cada etapa del proceso.

Se ha observado cierta confusión en el concepto de "open apex" y en el manejo de los problemas relacionados con la comisionación de compras. Es esencial aclarar estos puntos y tener cuidado al presentar la tecnología utilizada, especialmente si el equipo es responsable de su desarrollo. Para aquellos que están al fondo de la sala, sería más efectivo incluir un video.

Es importante señalar que los riesgos que se mencionan son, en última instancia, problemas de comunicación. En lugar de enfocarse únicamente en modelos UML, se debe dar prioridad a la definición clara de la interfaz y los contratos que faciliten la interacción entre los diferentes elementos del proyecto.

Por último, el despliegue debe planificarse con antelación, evitando integraciones continuas a última hora. Una acción clave es mejorar el sistema y establecer cómo mediremos la efectividad de la solución propuesta para el problema identificado.

Preguntas para el Grupo 11

1. ¿Cómo habéis calculado el tiempo de respuesta de cada miembro del equipo para el análisis de rendimiento?
2. ¿Cómo habéis gestionado la comunicación entre el equipo de backend y el equipo de frontend para asegurar que las tareas se realicen correctamente?
3. ¿El usuario de gestión debe registrarse previamente, o es un usuario reservado únicamente para la gestión?

Feedback Positivo

• El análisis de costes está bien representado y explicado, destacando los números principales.
• La planificación de los futuros sprints está claramente explicada.
• Buena organización en la gestión de los usuarios piloto.

---

Grupo 10

Observaciones Generales

El "killer opener" es un buen inicio, pero puede mejorarse. Actualmente, plantea preguntas al público que asumen que la situación es negativa, lo que puede desconectar a quienes no se sientan identificados. Es importante reformularlo para que sea inclusivo y capte la atención de todos, incluidos los profesores. Además, debe evitar referencias al alcoholismo, ya que este tema puede no ser bien recibido en contextos multiculturales.

En lugar de apelar a la mala vida nocturna, sería beneficioso explorar un enfoque más positivo y social, como asociarse a iniciativas de concienciación, lo que podría resultar atractivo y relevante. El nombre del proyecto, que está en inglés, puede no tener sentido si se dirige únicamente a un público español; se recomienda adaptarlo al contexto local.

Se ha valorado positivamente la transparencia en la presentación de gastos, así como las transiciones entre las diapositivas, que han mejorado notablemente. Sin embargo, se observó que algunas gráficas son diferentes entre sí cuando podrían presentarse de forma consolidada. Es crucial explicar las razones detrás de las caídas en los meses cinco y seis y asegurar que las cifras sean claras y visibles.

Además, se debe cambiar la referencia de "semana" a "meses" para reflejar adecuadamente la estimación de ingresos. Las gráficas son en general muy buenas, pero la estimación media debe reformularse para que refleje la estimación esperada, en lugar de promedios entre cifras optimistas y pesimistas.

También se destacó que el concepto de "full stack" cubre un amplio espectro tecnológico. Si todos los miembros del equipo son considerados full stack, no es necesario hacer distinciones. Esto proporciona mayor flexibilidad en la organización del trabajo.

En la demo, se sugiere simplificar el proceso de registro y login, centrándose en la reserva, que es el aspecto más importante. Los vídeos de transición deben ser más rápidos y estar mejor sincronizados. Se recomienda hacer zoom en las partes clave del video para mejorar la visualización.

La diapositiva 15 presenta demasiado texto; sería más efectiva si se dividiera en tres partes y se utilizara más contenido visual y metáforas. Si se van a comentar problemas, es preferible abordarlos antes de la retrospectiva para que no se genere una percepción negativa.

En cuanto a la gestión de los usuarios piloto, ha faltado información sobre el análisis del feedback recibido. Es importante que este feedback sea analizado, categorizado y priorizado, ya que esto influye en la replanificación del Sprint 2 y en la inclusión de tareas para abordar los comentarios recibidos.

Feedback Positivo

• Se ha elogiado la presentación de los gastos y se ha solicitado más movimiento en las transiciones.
• Las gráficas han sido bien recibidas, aunque se recomienda explicar mejor la estimación de ingresos.

---

Grupo 8

Observaciones Generales

La presentación no ha logrado captar la atención del público; ha sido bastante neutra en su enfoque. Se sugiere incorporar un elemento llamativo, como un muñeco, que podría generar interés y conectar con la audiencia. Aunque la explicación del proyecto es muy buena, carece de impacto y parece que se ha dedicado demasiado tiempo a detallar el producto. Es importante no alterar el MVP en esta fase.

Además, la presentación incluye demasiada información en algunas partes, lo que dificulta la comprensión. El formato general es espectacular, pero la utilización de muñecos es inconsistente; en algunos casos, no transmiten el mensaje deseado. En la sección de competidores, es correcto mantener una homogeneidad en el formato, pero no hay que temer a utilizar colores llamativos, como el rojo, que pueden captar la atención.

En los mockups, es esencial evitar el uso de texto de ejemplo como "lorem ipsum", y es positivo que se utilicen datos realistas en la demo para mostrar lo fácil que es introducir información. En lugar de requerir registro o login, sería suficiente con mencionar que estas funciones están disponibles.

Es preferible contar la historia desde la perspectiva del usuario para mejorar la experiencia, lo que puede conectarse con el inicio efectivo. Además, se debe revisar la disposición de los elementos en la presentación, evitando que el botón de retroceso esté demasiado cerca de la esquina.

En cuanto al equipo, se ha notado una estructura demasiado piramidal. Aunque son 15 miembros, no se puede considerar que sea un grupo excepcional. Para la toma de decisiones, es útil tener una jerarquía clara, pero cada uno de los estratos debe tener un propósito definido. Mantener esta estructura es beneficioso, aunque se sugiere que se asuman varios roles para fomentar una mayor colaboración.

El análisis del rendimiento debe incluir la identificación de "code smells". Es crucial aplicar herramientas como Sonar para analizar el código y garantizar su calidad. Además, es recomendable realizar un análisis de cada Sprint durante los despliegues de la aplicación para poder observar la evolución y las mejoras a lo largo del desarrollo.

Sería útil implementar un sistema de integración continua, utilizando Pull Requests (PR) para optimizar este proceso. Los desarrolladores deben tener la oportunidad de corregir el código que han entregado, lo que les permitirá aprender y mejorar. También es positivo que se analicen y prioricen los comentarios de los usuarios piloto, de los cuales se mantienen 8.

Entendemos que encontrar usuarios piloto puede ser complicado, por lo que se podrían explorar nuevas estrategias para reclutarlos. En relación a la inteligencia artificial, se debe profundizar más en su análisis y no limitarse a describir su uso.

Preguntas para el Grupo 8

1. ¿Por qué se utilizan datos ficticios en la demo?
2. En el análisis de rendimiento, ¿se debería abordar las amenazas como problemas y ofrecer soluciones?
3. En la parte de usuarios piloto, ¿cómo se gestionará la comunicación para evitar la pérdida de opiniones?

Feedback Positivo

• La representación del MVP ha sido bien recibida, siendo clara y concisa.
• La tabla comparativa de estimaciones y resultados es efectiva y facilita la comprensión del progreso.

---

Grupo 7

Observaciones Generales

En la DEMO, se experimentó el "efecto pantalla azul", lo que dejó una impresión negativa en la presentación. La forma de dividir el contenido en distritos es interesante, pero sería beneficioso considerar la integración de Google Feed para incorporar dispositivos que puedan recoger información en tiempo real. Esto podría ofrecer ciertas ventajas, aunque es necesario prestar atención a los permisos requeridos por las aplicaciones móviles para asegurar una correcta funcionalidad.

Es fundamental incluir los comentarios de la entrega para permitir modificaciones en las diapositivas, ya que esto es un requisito legal que no debe pasarse por alto. Además, se observa que, con respecto a los problemas no previstos, no se han actualizado los riesgos. Esto ha ocurrido porque los problemas han estado muy interrelacionados, y no ha habido tiempo suficiente para registrar cada uno de ellos.

Se recomienda centrarse en lo esencial y evitar incluir información innecesaria o mal organizada. Si no hay aspectos destacados, es preferible mencionar lo que se ha cumplido y omitir detalles superfluos. Es crucial resaltar la evolución y el impacto de las penalizaciones en los futuros sprints.

Se sugiere que se incluya un diagrama de Grant para facilitar la comprensión de los procesos, ya que la falta de claridad en el significado de los colores utilizados genera confusión y requiere un esfuerzo cognitivo innecesario. En cuanto al uso de la inteligencia artificial, se ha hecho un buen trabajo al proporcionar ejemplos y detalles. Sin embargo, es fundamental que se ofrezca suficiente información al respecto; de lo contrario, podría ser motivo para recibir una calificación baja.

Feedback Positivo

• La gráfica de comparativa de costes e ingresos está bien representada y es fácil de entender.
• La división del mapa en distritos es innovadora y aporta interés a la presentación.

---

Grupo 9

Observaciones Generales

Estéticamente, la presentación está muy bien elaborada. Se nota el esfuerzo en la calidad de la información y en cómo está estructurada, lo que la hace visualmente atractiva y fácil de seguir. Sin embargo, los porcentajes presentados en la parte inferior no han sido bien recibidos. Es importante que el equipo tome la iniciativa para abordar este aspecto.

En relación a los usuarios piloto, es necesario filtrar el feedback recibido, ya que no todas las opiniones son relevantes. Si bien se pueden observar las tendencias, es fundamental que la información no se presente de manera aislada; en cambio, debe reflejar la evolución acumulativa mes a mes. Al superponer la curva de beneficios con la curva de pérdidas, la comprensión de la situación será mucho más clara.

En la sección del equipo, es importante mostrar quiénes son, cómo generan ingresos y cómo trabajan. Sin embargo, se ha notado que no se incluyen fotos de los miembros del equipo. Aunque esto no es un problema en sí mismo, transmitir el número de integrantes es esencial. Las imágenes no deberían repetirse; si se presentan varias responsabilidades, es recomendable incluir una imagen que muestre al equipo y otra que explique los roles sin necesidad de fotos adicionales.

Además, se debe contar con una matriz que refleje las responsabilidades de cada miembro. En cuanto a la evaluación, los decimales no aportan información relevante. Se debería marcar claramente el tiempo transcurrido y las horas trabajadas por cada persona, ya que actualmente no se visualizan correctamente en la evaluación del Sprint 1. Las horas totales no son útiles si no se contextualizan adecuadamente.

Es fundamental comenzar a trabajar en la garantía de calidad, asegurándose de que todo esté debidamente probado. Algunas funcionalidades, como las APIs externas, pueden ser complicadas de probar sin cometer errores. Los sistemas de pago cuentan con un entorno de sandbox, pero se debe proceder con precaución en otras áreas. Además, los porcentajes presentados no permiten evaluar si son altos o bajos. Es crucial centrarse en corregir los aspectos con mayor incertidumbre de inmediato.

Feedback Positivo

• La funcionalidad de la aplicación es intuitiva y facilita la visualización del contenido.
• La parte de lecciones aprendidas está bien estructurada y se aprecia el enfoque en el análisis del feedback recibido.

---

Apuntes Finales

Aspectos Contables

Los conceptos de CAPEX (gastos de capital) y OPEX (gastos operativos) deben ser claramente diferenciados. Los activos son elementos con valor económico, y en nuestro caso, tratamos con activos intangibles que son difíciles de medir. Las horas de trabajo de una persona en el desarrollo de un producto se convierten en una inversión, y desde una perspectiva contable, esto implica transformar recursos en activos cuantificables.

Es fundamental activar la investigación y desarrollo (I+D) para transformar conocimientos en activos. Las empresas que generan beneficios deben pagar impuestos correspondientes, lo que significa que las horas de trabajo se convierten en activos gestionables. Los gastos de personal son costos operativos, y es importante no confundir la necesidad de ser realistas en la estimación de ingresos sin limitar el diseño del producto a contextos específicos.

La gestión de despliegues requiere atención para evitar la pérdida de funcionalidades. La automatización de la calidad del código con herramientas como Sonar es esencial, pero todos deben comprender su funcionamiento. En algunos proyectos, falta un informe adecuado sobre el uso de la inteligencia artificial, y no se está aprovechando la tecnología de manera efectiva, optando por construir sistemas desde cero en lugar de utilizar soluciones manuales.

Al diseñar productos, se debe asegurar que no estén contaminados por restricciones innecesarias. Además, el uso de autenticación social podría facilitar el inicio de sesión mediante plataformas como Facebook o Google, eliminando la necesidad de gestionar usuarios y contraseñas. Finalmente, es importante tener en cuenta que herramientas como Copilot pueden no captar el contexto de manera adecuada.

Para la Próxima Semana

1. Presentación de Impacto/Marketing:

   • Iniciar con la parte inicial del modelo de negocio.
   • Crear una presentación que incluya un storyboard visual.
   • Definir cómo se llegará a cada tipo de usuario e inversores.

2. Consideraciones para Inversores:

   • Enfocarse en la rentabilidad y en motivar a los inversores a comprar.

3. Elementos a Incluir:

   • Presentar el "killer opener" y la "elevator pitch".
   • Identificar y analizar a los competidores.

4. Impacto Legal:

   • Incluir aspectos legales del proyecto (licencias, acuerdos con clientes, etc.).
   • Analizar la Ley de Protección de Datos y su impacto en la planificación.

5. Aspectos Financieros:

   • Establecer una línea base para gastos e ingresos.
   • Incluir estimaciones optimistas de ingresos y presentar proyecciones gráficas.

6. Estructura del Equipo:

   • Definir roles y responsabilidades dentro del equipo.

7. Mitad del Sprint:

   • Preparar una demo del avance del proyecto.

8. Casos de Uso y Desarrollo:

   • Establecer los casos de uso principales y destacar incrementos en el desarrollo.
   • Comentar problemas y novedades con transparencia, utilizando datos reales.

9. Retrospectiva:

   • Analizar lo que ha ido bien y mal, enfatizando la garantía de calidad con datos relevantes.

10. Seguimiento de Usuarios Piloto:

    • Realizar un seguimiento del rendimiento de los usuarios piloto en el Sprint 2.

11. Objetivos Finales del Sprint:

    • Incluir pagos reales utilizando cuentas sandbox.
    • Asegurar que la funcionalidad de pago sea una parte clave del producto mínimo viable.

12. Estructura y Detalles en el Proyecto:

    • La explicación del proyecto debe ser compacta e incluir anuncios.
    • Identificar y abordar los problemas del primer sprint, minimizando su frecuencia en futuros sprints.

13. Costes e Infraestructura:

    • Revisar los costes de infraestructuras y de personal.
    • Considerar la necesidad de un manager de gestión de datos y de mercado.

14. Diferenciación para el Sprint 2:

    • Mantener la misma estructura con actualizaciones en pagos reales, registro, usuarios piloto, y contratos.
    • Incluir detalles sobre ingresos y tres tipos de escenarios, así como la gestión de OPEX y el personal en relación con aspectos legales y storyboards.

Semana 6

Grupo 9

La presentación fue clara y bien estructurada, con un killer opener que captó la atención del público. Se recomienda reforzarlo con elementos visuales o una despedida más impactante para hacerlo más memorable.

El storyboard está bien planteado y transmite emociones de manera efectiva. Se sugiere mejorar la visibilidad de ciertos elementos con acercamientos en frases clave. La gráfica de monetización es excelente, y en cuanto al lenguaje, es preferible referirse a "gastos" en lugar de "pérdidas" para evitar connotaciones negativas.

Respecto a la normativa GDPR, es clave considerar su impacto en la implementación del proyecto, especialmente en temas como el derecho al olvido y los mecanismos de denuncia. No se trata de automatizar todo, sino de establecer procesos adecuados que cumplan con la normativa sin comprometer la seguridad de los datos. También es fundamental medir el tiempo de reuniones y establecer métricas para evaluar el progreso.

El equipo ha invertido muchas horas en el proyecto, y si es necesario, se puede ajustar el alcance para optimizar esfuerzos. La tecnología debe utilizarse de manera estratégica, enfocándose en lo que realmente aporta valor. La autenticación y otros aspectos técnicos deben evaluarse en función de su impacto en la productividad. El product backlog está bien estructurado, y se recomienda medir también los retrasos en las tareas.

En la demo, sería útil indicar qué caso de uso se está mostrando y utilizar un icono de usuario en progreso para mejorar la comprensión. Es recomendable mostrar el video en el momento adecuado sin adelantar información.

El uso de Códacy es positivo, pero se sugiere no limitarse a lo que muestra la plataforma, sino analizar las métricas y su evolución. Es importante monitorear los "bad smells" para mejorar el rendimiento. La falta de una métrica clara sobre el rendimiento del proyecto es una debilidad y podría afectar la evaluación del entregable. También se recomienda mejorar la comunicación y establecer mecanismos para detectar y solucionar problemas, como el uso de Niko Niko para evaluar la efectividad del equipo.

Grupo 10

Las presentaciones están mejorando en calidad y estructura, pero aún hay aspectos por pulir. La introducción explicó bien el proyecto, aunque no enfatizó suficientemente en su propósito exacto. La mención de la venta de entradas puede llevar a confusión, por lo que se recomienda destacar la experiencia diferenciadora desde el killer opener. No se aconsejan preguntas abiertas en esta sección, sino construir una narrativa efectiva.

En términos técnicos, los costos de personal deben presentarse como una inversión, no como un gasto. En la presentación, no es necesario mostrar la fórmula completa, sino solo los factores clave y un resumen. La explicación debe ser intuitiva y centrarse en las variables relevantes en lugar de la ecuación en sí. En cuanto a temas legales, se debe resaltar que el código no debe ser público y que los profesores pueden tener acceso sin necesidad de abrirlo completamente.

El storyboard debe evitar la "magia" de la aplicación y enfocarse en la historia desde el inicio. En la demo, es crucial indicar el tiempo restante hasta la siguiente pista. La velocidad de la presentación debe ajustarse para facilitar el seguimiento. Si el registro no es imprescindible, puede omitirse para agilizar la experiencia del usuario. Se recomienda mejorar la presentación de la información en la encuesta y otras secciones para asegurar su comprensión. Por ejemplo, los datos monetarios pueden mostrarse en una barra en lugar de números.

Uno de los problemas recurrentes es la falta de comunicación. Simplemente eliminar a miembros del equipo no es una solución; se deben implementar mecanismos de seguimiento para evaluar la efectividad de las medidas adoptadas. Es importante analizar las razones detrás de los problemas, como la falta de pruebas o la ineficacia de las pull requests. En la tabla de planificación de usuarios piloto, se recomienda mejorar la visualización de las fechas para mayor claridad.

Grupo 11

El killer opener captó la atención, pero la estructura de la presentación podría mejorar con una mejor transición entre secciones. Se sugiere reforzar el cierre con un call-to-action más claro.

El storyboard es sólido, pero faltó claridad en algunos elementos visuales clave. Se recomienda mejorar la sincronización de las animaciones con la narración para mayor impacto. En cuanto a métricas, se debe incluir un seguimiento más detallado del progreso del equipo.

La demo fue efectiva, aunque se podría mejorar la navegación para que el flujo sea más intuitivo. Es importante también enfatizar cómo la solución se diferencia de alternativas existentes en el mercado.

Grupo 7

El equipo mostró una gran evolución en la presentación, con una introducción bien definida. Sin embargo, se notó cierta rigidez en la exposición. Se recomienda practicar más la naturalidad al presentar.

La estrategia de monetización generó dudas en la audiencia. Es importante clarificar los costos y beneficios del modelo de negocio para evitar confusión. También se sugirió mejorar la forma en la que se presentan los datos de mercado para hacerlos más persuasivos.

El storyboard refleja bien el uso de la aplicación, aunque algunos aspectos parecían demasiado ideales. Se recomienda incluir más ejemplos de posibles dificultades que puedan surgir y cómo abordarlas.

Grupo 8

El grupo logró captar la atención con un inicio dinámico, pero algunas secciones de la presentación fueron demasiado técnicas. Se recomienda simplificar ciertos conceptos para que sean accesibles a toda la audiencia.

El diseño visual de las diapositivas es atractivo, pero en algunos casos la cantidad de texto dificultaba la lectura. Se sugiere resumir información clave y apoyarse en gráficos para hacer la presentación más digerible.

La demo fue funcional, pero faltó contexto al explicar cada paso. Es importante guiar a la audiencia a través de la solución con ejemplos prácticos y destacar cómo resuelve un problema real.

Apuntes Finales

Aspectos generales

Anotaciones finales:

La próxima evaluación consistirá en una presentación de 15 minutos. Además, se introducirán nuevas píldoras teóricas que deberán ser revisadas para comprender mejor los conceptos y aplicar los aprendizajes.

En cuanto al Customer Agreement, es fundamental que este obligue al cliente a aceptar los términos de servicio. Además, debemos garantizar que tengamos evidencia de que el usuario ha estado de acuerdo con las condiciones, como las de uso. Un ejemplo de cómo hacerlo bien es PayPal, que cuando envía los textos legales, los resume de forma sencilla y clara para que el usuario pueda entenderlo fácilmente. Podemos adoptar un enfoque similar, asegurándonos de que el cliente pase por cada sección de los términos rápidamente pero de manera comprensible.

También tenemos la obligación de almacenar evidencia de que el cliente ha leído el documento legal. Como mínimo, debemos asegurarnos de que haya abierto el documento. Si lo ha leído, ya no es nuestra responsabilidad. Sin embargo, esta medida nos ayuda a protegernos y garantizar que el usuario está plenamente informado.

Sugerencias para mejorar los procesos:

En cuanto a la gestión de reuniones y la comunicación, algunos equipos, como el de comunicación, podrían beneficiarse de un calendario compartido para facilitar la organización de las llamadas, especialmente en grupos grandes. Esto ayudará a que todos estén al tanto de las horas disponibles y evitará confusiones sobre la disponibilidad.

Respecto a los ChangeLogs, estos son fundamentales para tener un registro claro de las actualizaciones y cambios en el proyecto. Es importante saber qué es nuevo y qué ha cambiado. Utilizar herramientas como Conventional Commits puede ayudarnos a definir una estructura para los commits, asegurando que todos sigan el mismo formato y que el historial de cambios sea coherente y fácil de entender.

Por último, en cuanto a los usuarios pilotos, es esencial llegar a un acuerdo formal con ellos. No se trata solo de tener un plan, sino de formalizar los compromisos a través de un documento de términos de relación. Por ejemplo, el proyecto debe comprometerse a desplegar el sistema en una fecha concreta, mientras que los usuarios pilotos deben completar sus tareas dentro de un plazo determinado. De esta forma, ambas partes se comprometen de manera clara y formal.

Para la Próxima Semana

• No cambios en porcentajes, agregar.

• El storyboard debe tener uno para cada tipo de cliente: clientes del establecimiento, clientes de mascotas, usuarios e inversores.

• Evitar cláusulas abusivas en los términos de servicio. Si hay alguna cláusula abusiva, justificarla. El Customer Agreement debe incluir la información sobre los términos de servicio y lo que ofrece el servicio. No se puede obligar al cliente a dar información. Hay herramientas para evitar cláusulas abusivas. Definir los términos de servicio en el Customer Agreement.

• No ha habido tiempo de respuesta ni de disponibilidad del servicio al cliente. Si dependemos de APIs externas, como en el caso del mapa, debe indicarse.

• El pricing debe ser lo más claro posible. Las tablas de precios son casi una obligación, y deben usarse para definir nuestro modelo de negocio.

• Los SLA, licencias y la protección de datos deben definirse claramente. También se debe especificar el uso de APIs externas y cómo nos comprometen, especialmente con el procesamiento de datos personales.

• El análisis de costes se estandariza ahora a 2 años, comenzando desde el primer día del cuatrimestre. Se debe distinguir entre CAPEX (inversiones) y OPEX (gastos operativos). CAPEX se refiere a inversión, no a gastos.

• La retrospectiva es lo más importante. Mostrar una matriz de rendimiento y esfuerzo, enfrentando a cada miembro con estos dos factores. Cada persona es un punto, y la gráfica debe mostrar el rendimiento y esfuerzo. Incluir una línea de 10 horas como referencia.

• Gestionar el feedback revisando las píldoras teóricas.

• En la planificación del Sprint 3, tener en cuenta lo que viene después del Sprint 3, incluyendo el pago real (que funcione el caso de uso del pago), el registro y pago deben incluirse. Aspectos de seguridad son muy importantes. Validar datos como cuentas de correo, teléfonos, direcciones y tarjetas de crédito. Usar APIs para verificación.

• Si se reduce el alcance del proyecto, hay que replanificar. Si hay tiempo, se puede realizar un Sprint 4 hipotético y plantear qué hacer si algo no cabe en el Sprint 3.

• Analizar el uso de la IA, cómo está ayudando y si está mejorando. Incluir las lecciones aprendidas, especialmente de los storyboards, y documentar las alucinaciones encontradas de la IA.

---

Semana 7

Grupo 9

Positivo

• La esquela está muy bien, se puede ver mientras se edita y permite cambiar el color a gusto.
• Los storyboards han sido muy visuales.
• Explicación clara del customer agreement, incluyendo detalles como el TTO.
• Buena idea implementar castigos para incentivar el feedback, ha resultado en un aumento de respuestas.
• Llama la atención la gran bajada de code smells. El grupo ha pasado de 4 a 0.5, lo cual suele llevar mucho tiempo.

Feedback

• Muy buen trabajo y presentación.
• El inicio efectivo ha mejorado, apoyado por elementos visuales.
• El elevator pitch da una idea clara del proyecto, aunque podría haberse enriquecido usando los storyboards.
• El flujo ideal sería: Elevator Pitch → Storyboard → Competidores (con introducción) → Demo, para mejorar la conexión.
• El commitment agreement no queda claro si se ha pasado a Claudette, se debería remarcar si se ha utilizado.
• En la demo no se ve bien, deberían hacer zoom.
• El análisis de los 4 cuadrantes se ha explicado bien, con buen uso del zoom.
• Muy bien explicado el burn up y burn down.
• Horas extra: no se han gestionado bien. Se podría replanificar o reducir la carga en próximos sprints.
• Calidad del código y Códacy: muy bien.
• Si priorizan a los usuarios piloto, se debería mostrar el feedback específico y cómo eso impacta en la priorización.
• Mejorar la comunicación con los usuarios piloto, hacerlos sentir escuchados.

---

Grupo 7

Positivo

• Fuente de ingresos y proyección de gastos/ingresos bien explicadas.
• Mejora estética de la presentación.
• Buena conexión entre el inicio efectivo y los storyboards.
• Retrospectiva mejorada, con propuestas concretas para el Sprint 3.
• Se ha explicado de forma muy intuitiva qué ha ido bien.
• Encuestas a usuarios piloto bien estructuradas, completas y útiles.
• Se han definido ventajas para los usuarios piloto en la app.
• Uso de IA para analizar el feedback de los usuarios piloto.

Feedback

• El killer opening puede mejorar mucho. Podría haber una simulación de uso de la app.
• Los 100€ por empresa en el modelo de negocio no cuadran, explorar diferentes opciones y analizar el mercado (comparar con videojuegos, ajustar precios).
• Los storyboards deben ser independientes, sin mezclar cliente e inversores.
• Para inversores: resumir mucho la idea, ir directo a los números, beneficios e inversión.
• Uno de los storyboards debe convertirse en un anuncio real la próxima semana.
• El análisis de precios no se ve claro, mejor usar solo una tabla para claridad.
• Evitar nombrar al equipo individualmente, ser más cuantitativos.
• El pricing aparece en la demo, ahí se debería diferenciar bien entre usuarios premium y no.
• Calidad del código: analizar buenas y malas prácticas, comparar con el avance del resto.
• Más relevante identificar retrasos que avances.

---

Grupo 11

Positivo

• Inicio efectivo muy potente, buena energía y habilidades de presentación.
• La demo se ve bien desde atrás y tiene buen ritmo.
• Gráficas de costes claras e intuitivas.
• Se han mencionado los aspectos negativos del uso de la IA, lo cual es positivo.

Feedback

• El presentador va muy rápido, cuesta seguirle.
• Debería practicar con un familiar antes de la presentación para mejorar ritmo y claridad.
• 50 transparencias son demasiadas; sobra al menos 5, sobre todo con una demo en medio.
• Muy buen killer, pero falta conexión con la demo. Deben tener un hilo conductor común.
• María Jesús debería aparecer si es la imagen del trabajo.
• En análisis de competidores: resaltar puntos de comparación clave y estimaciones (ganancias, costes).
• Costes, ingresos y TCO deben estar mejor especificados.
• Justificar la inversión como algo que se amortiza, no solo como gasto.
• Explicar el bajo rendimiento del grupo en el sprint 2 de forma clara.
• Evitar rodeos al mostrar evolución del rendimiento; usar métricas claras.
• Si hay figura de mediador, especificar su rol y evolución (positiva/negativa).
• En la demo, si se muestran precios, usar rangos más realistas (950€ es poco creíble).

---

Grupo 10

Positivo

• No venden datos a terceros, buen enfoque ético.
• Ritmo adecuado en la presentación, sin necesidad de correr.
• Storyboards bien planteados y gráficamente atractivos.
• Idea de buscar una mascota y un slogan es excelente.
• Uso de preguntas y respuestas durante la presentación como técnica narrativa.
• El análisis de costes se ha planteado correctamente: CAPEX al inicio, no pérdidas reales.
• Reflexión legal sobre la edad mínima acertada: mejor usar filtros que excluir población.
• SLA pendiente, se debe implementar.
• Retrospectiva bien estructurada: detectar y resolver problemas rápidamente.

Feedback

• El inicio efectivo fue muy coloquial (“cojones”), lo cual desconecta a parte del público. Usar lenguaje más neutro.
• Mirar a todo el público, no solo al profesorado.
• Cambiar el tono emocional de los presentadores si es muy deprimente.
• En gráficos y números, separar bien conceptos de costes, inversión y rentabilidad.
• Al hablar de legalidad, plantear opciones para menores de edad con filtros adecuados.
• Evitar tomar decisiones por presión; mantener visión de largo plazo.
• Retrospectiva algo repetitiva, mejor resumir.
• En la demo: mostrar con ejemplos concretos (e.g., caso de Pablo).
• En diapos como la 36, usar puntos conectados para visualizar mejor la evolución grupal.

---

Grupo 8

Positivo

• Excelente killer opening.
• Mejora notable en los storyboards, se presentan como una historia real.
• Interfaz atractiva, con buena visualización tipo calendario.
• Análisis detallado del código con plan de acción.
• Priorización efectiva del feedback de usuarios piloto.
• Buenas lecciones aprendidas del uso de IA.
• Integración de Stripe en la app.

Feedback

• Buena presentación, killer bien conectado con la demo.
• Si se presenta una foto de mejora, usar icono visual para destacar que el usuario lo usa.
• Para inversores: usar metáforas visuales, ir directo a los datos, sin texto plano.
• En el customer agreement, usar metáforas o destacar elementos clave, no leer todo.
• En retrospectiva: usar iconografía visual y palabras claves.
• En métricas de código, calificación E debería cambiarse. Mostrar márgenes de mejora.
• Si no han usado bibliotecas, deben tratar la seguridad.
• Mejor hablar de puntos de mejora en términos de progresión (cómo se avanza).
• Recordar: los costes también implican ingresos, no solo gastos.

---

Indicaciones Generales para la Próxima Semana

Temas Clave:

• Storyboards: al menos uno debe ser un anuncio real. Puede ser grabado o generado con herramientas.
• Introducción: mantenerla, pero usar el storyboard como transición.
• Sprint 3: explicar qué ocurrió en la primera mitad.
• UI/UX: mostrar mejoras según feedback de usuarios piloto.
• Regulación: incluir aspectos de privacidad y datos.
• Retrospectiva:
  • Evaluar si los problemas se están solucionando.
  • Mostrar evolución de soluciones.
  • Usar métricas para valorar efectividad.
  • Hacer predicciones de mejora (apuestas numéricas).
• Usuarios Piloto:
  • Hacer ranking de acciones según feedback.
  • Analizar caídas o mejoras por categoría.
• API: tener plan B si alguna falla.
• Marketing: comenzar a pensar estrategias (redes sociales, comunicación).

---

Semana 8

---

Grupo 8

• El anuncio debe contar una historia por sí mismo, no delegar esta función únicamente al storyboard.
• Faltan fotos reales de las recetas; actualmente solo hay contenido tipo lorem ipsum, lo cual es inaceptable a estas alturas. Se necesitan imágenes auténticas.
• En la DEMO se habla de productos que no están presentes en la propuesta actual. Se ha planteado todo a nivel de producto, lo cual no se refleja claramente.
• En la evaluación del tiempo no se especifica si se habla de horas o minutos. Es fundamental controlar que se cumplan las 10 horas semanales.
• Fallos como los del tipo “Fallo x en frontend” pueden evitarse. Si es un error de despliegue, existen formas de detectarlos antes que los usuarios pilotos. Se recomienda implementar sistemas de alerta.
• Es muy positivo que hayan priorizado las tareas de los usuarios pilotos, así como la puntuación de los mismos.

Grupo 9

• El video es visualmente excelente, casi cinematográfico, aunque un poco largo.
• El elevator pitch ha sido muy claro y conciso, con pocos elementos que cambiar.
• El video para inversores está muy bien, aunque le faltan opciones de inversión, su rentabilidad y otras alternativas.
• Los colores usados para capex y opex no coinciden, lo cual genera ruido visual.
• Para el PPL, hay que pensar en estrategias para ganar tracción e involucrar al personal en el uso de la aplicación.
• Se sugiere mostrar las horas medias trabajadas superpuestas en gráficos, comparándolas con una semana normal. Las barras deberían dividirse en dos partes para mostrar la media.
• Algunas partes del feedback recibido pueden ser ignoradas.

Grupo 10

• El tiempo de disponibilidad está basado en el tiempo de no disponibilidad. También hay que considerar las tasas de error.
• No comprenden por qué algunos correos llegan a spam; puede deberse a ciertas palabras clave.
• El slogan está muy bien, aunque se han autocensurado bastante.
• El anuncio es un muy buen intento y resultó entretenido, aunque un poco largo. Podría acortarse.
• En el video, lo relacionado al móvil no se ve claro. Puede colocarse a un lado o enlazarse con la presentación de ISPP.
• Se recomienda simplificar y eliminar elementos como la opción de “contraseña olvidada”, ya que no aporta valor a esta etapa.
• El anuncio presenta acciones de team building, como hacer algo juntos (por ejemplo, tomar una Coca-Cola).
• La idea para el world planned launch está bien planteada, sobre todo para introducir la app al resto de los compañeros.
• En el análisis de optimistas/pesimistas, faltan las personas. No usar "L", sino explicar qué significa.
• Hay trazabilidad entre los problemas de la demo anterior y la siguiente, pero hay cuestiones que no encajan bien.
• En las diapositivas, se sugiere presentar problema y solución en la misma, para mayor claridad.
• En el rendimiento, el sistema verde/rojo funciona bien para identificar cumplimiento. Falta indicar quién se excede del tiempo.
• Se pueden añadir promedios a las barras, y usar líneas discontinuas con dos puntos para mostrar evolución y tendencia.

Grupo 11

• Evitar usar palabras en inglés innecesariamente si hay equivalentes en español.
• Se deben definir y repetir claramente las palabras clave en la presentación.
• Muy buena diferenciación respecto a los competidores, está bien resaltado.
• El discurso está muy bien ensayado. El anuncio es muy profesional y quieren reutilizarlo en otros años.
• El storyboard de usuarios está muy bien logrado. La parte de usuarios es destacable.
• Cuidado con los ejes en los gráficos, ya que algunos no se ven bien. Asegurarse de que las unidades (como "k") estén claras.
• La sección de protección de datos resulta anticlimática y rompe el ritmo. El impacto legal debe tratarse de forma más fluida.
• Aunque el customer agreement ya no es obligatorio, puede seguir mejorándose.
• Hay una incongruencia en las gráficas: no tiene sentido que una persona con 6 horas logre lo mismo que otra con 12.
• La parte de usuarios pilotos es increíblemente bien trabajada.
• Los problemas técnicos deben resolverse primero, ya que muchos impiden casos de uso, aunque el objetivo sea comprender mejor al usuario.
• Si alguien del grupo no trabaja adecuadamente, primero se debe mostrar evidencia al profesorado antes de tomar medidas como su expulsión.
• Primero debe primar la empatía y luego el commitment agreement.

Grupo 7

• El partnership con usuarios es parte del coste de marketing para captar nuevos clientes.
• Se pueden crear campañas de TikTok, como retos, para aumentar usuarios (idea propuesta por Ale).
• Muy buen inicio efectivo.
• El anuncio menciona funcionalidades extras que no se detallan.
• El storyboard para inversores es el primero en presentar opciones de inversión.
• El plan de precios para empresas ha sido bien recibido, incluyendo opciones compensadas, no solo tarifas fijas mensuales.
• La proyección financiera tiene dos ejes que no se entienden. Pablo Trinidad no lo comprendió.
• En la DEMO, no queda claro a quién va dirigida (empresa o usuario). Si el inicio efectivo es X, unirlo con esa sección y mostrar los iconos de los usuarios activos en ese momento.
• Para tareas incompletas, mostrar aproximaciones. El número 32 ha sido valorado como perfecto.
• El color puede utilizarse para marcar direccionalidad e importancia temporal.
• Las líneas horizontales/punteadas no deben ser tan anchas. Las principales deben destacarse más.
• Incluir flechas puede ayudar a mostrar hacia dónde se dirige la visualización.
• La calidad del código es excelente, como se solicitó. Se puede ampliar la información si es necesario.

---

Indicaciones Generales

Tareas Extra y Recuperación de Nota

• Habrá una tarea extra individual que permitirá subir medio punto si se aprueba.

• Se dará más información próximamente.

• También se puede entregar un documento grupal de lecciones aprendidas del sprint 1 y 2 para recuperar parte del porcentaje no apto.

• Este documento permitiría mejorar la nota de entregas anteriores, recuperando hasta la mitad del porcentaje perdido.

• Los usuarios pilotos continuarán la semana que viene.

• Se mantienen los failure conditions del sprint anterior.

• Algunos grupos no hicieron testing. El plan de testing debe formalizarse, indicando:

  • Módulos evaluados
  • Tipo de pruebas realizadas

• Usar una matriz de trazabilidad como propone Ayure, relacionando casos de uso con módulos cubiertos.

• La planificación del sprint 4 puede formar parte del PPL como trabajo futuro.

• Mejor presentar acciones planeadas y concretas.

---

Para la Siguiente Semana

• Algunos grupos han tenido conflictos internos que pueden llevar a expulsión de miembros. La decisión final es del propio grupo.
• Se espera: un anuncio en video basado en el segundo storyboard. Puede ser el mismo, pero refactorizado. Idealmente, hacer uno nuevo.
• Si hay tiempo, se pueden entregar dos videos (el refactorizado y el nuevo). Si no, solo uno.
• Duración: videos cortos, no más de 2 minutos. Si se hacen dos: uno para inversores y otro para usuarios.
• La presentación de 15 minutos debe incluir:
  • Killer opener (3 min)
  • Anuncios
  • Elevator pitch
  • Análisis de competidores
• No olvidar incluir:
  • Tareas preliminares de marketing
  • Tracción inicial
  • Estrategias para ganar nuevos clientes
  • Planificación futura de atracción inicial
  • Distribución de tareas en el equipo
  • TCO (Total Cost of Ownership) de forma compacta
  • Costes actualizados del estudio preliminar de marketing
  • Nuevos roles del equipo en marketing
  • Retrospectiva habitual

---

Semana 9

---

Grupo 10

Más que inversor es de negocio, del cliente que es la empresa. Faltaría el story board del inversor. Inversor es el que soporta los costes de calidad. Falta hacer el del PPL el video del inversor. El killer opener es medio, hay que innovar un poco más. La primera vez empezó un poco más arriba, y el nivel de emoción parecía más enfadado. Esa falta de energía en el inicio hay que conseguirlo de nuevo. Que se lo tome de prueba para las siguientes presentaciones. Análisis de competidores, de forma en la que lo cuenta no es del todo convincente. Eso no lo tenía claro lo de definir en tema de viajes. Se puede apoyar con una metáfora visual. No son del todo competidores, se puede contar como algo similar pero que no es igual. Tiene que hacer el enfasis en la diferencia. Anuncios, el primero del cliente sigue siendo largo. Ese tipo de anuncios debe de ponerlo en el proyect launch, con menso tiempo. Si se puede quitar más tiempo para el discurso mejor. No le gusta en los roles del equipo muchas cabezas. Puede hacer una espeicie de tabla para mejorar la forma visual del mismo. En el de “inversores”, el anuncio no deja claro que es por eventos por sorpresa, se deja en el aire. El otro como que se lo cree pero no sabe por qué vienen. Debe ser un anuncio autocontenido. La demo le ha faltado zoom en algunas partes. Podría hacer algo parecido con sorpresóin, explicando el video mientras se hace la demo. Pagaría por ver a alguien vestido de sorpresín. Le ha dado la impresión del primer problema de entrar de vd en la causa del problema. Se ha quedado un poco en la superficie del mismo. Quien, por qué (Se han subestimado, si alguien ha desaparecido…) Si lo pone va a la raiz del problema, y es lo que ha faltado. El burndown y el control chart le permite analizar si es por el tipo de tareas que tenemos. A lo mejor se pueden poner tareas má s pequeñas. El resto de problema smuy bien explicados. No hace falta poner la evolución de la solución. La gráfica le ha quedado muy claro. Le ha gustado que hayamos hecho con Locust.

Cliente que es empresa el segundo story board, entonces nos faltaría el story board del inversor. Inversor es el que soportan los costes del proyecto. Son dos tipos de clientes. Hemos cumplido el requisito pero casi. El killer opener es medianamente efectivo, pero fue mas efectivo el primero, y en go4surprise espero sorpresa. Tambien hay un ingrediente que la primera vez empezaste un poc mas arriba, pero hoy hemos venido mas apagado porque nos dijeron que no podian decir palabrotas. Falta de energia en cuanto a las otras semanas. Para el PPL, innova y practicalo mucho. Se han dado cuenta hoy que el tema de los analisis de competidores no estan bien. Metafora visual apoyando lo que esta diciendo. Venta de entradas no es tanto un competidor, puede contarlo por algo similar pero hacer enfasi en la diferencia. No esta el tick para lo que ha dicho de experiencias alargadas en el tiempo. El anuncio de cliente le parece un pelín largo. El anuncio lo vamos a poner en el PPL y vamos a tener menos tiempo, intentar acortar. No le gusta roles, mejor en cuadro o mas metafora visual. Anuncio de inversor: en la discusión de las personas, no queda claro que le vienen clientes por evento sorpresa. El otro no sabe ni porque le vienen los clientes ni nada, el anuncio debe ser autocontenido , porq imagina q no han visto el video de antes. En la demo: le falta zoom en algunos momentos, e intentar coger lo bueno, hacer parecido algo con sorpresin haciendo el dialogo del video o interactuando con pablo. Problema 1: le ha dado la impresion de que no has terminado de entrar de verdad en la causa del problema, nos hemos quedado en la superficie, por no apuntar a la gente, ¿no se sabia la productividad de la gente?,¿gente que ha desaparecido?, hay q ser claro con la raíz del problema. Hay que poner lo que ha dicho pablo. ¿No tenemos problema actual de si solucionar o no? No tenemos, tenemos al project manager. Queda muy claro la grafica de rendimiento, bien con Locust. Analizamos de la maquina y no de en produccion, normalmente hacer una copia de la infraestructura para mantenerla durante 6,12,24 horas y ya simulas todo. Al final la capacidad de la maquina es en local.

Grupo 7

Aspectos positivos

• Muy bien el inicio efectivo, llama mucho la atención para que eches cuenta.

• El anuncio de inversores es de buena calidad, y me ha gustado como lo cuentan de forma de historia entre dos personas.

• El video de la DEMO es muy interactiva, con música de fondo y todo. Es lo que más me ha gustado, como hace zoom en las partes importantes y como visualmente se explica muy bien

• Muy bien explicado la gestión que llevan a cabo con los usuarios pilotos, además parece buena idea lo de los premios.x

Feedback

La energía ha sido buena, y aunque se rían está muy bien. La gentehace que te atienda. El anuncio de usuario está muy bien hecho. La semana pasada era más largo, pero tenía más interacciones. Del segundo video que compren bombillas, les hace falta. Buscar noticias cercanas en el tiempo para apoyar el video. Es bueno conocer el mercado y el tamaño del mismo. Les ha hecho falta entrar en detalle con lo que se ha comentado la semana pasada. Buen feedback en la DEMO. En el impacto legal hay tres niveles. Dependerá de donde se pueda utilizar la aplicación tendrá unas normas o restricciones legales. Aplica poco pero puede aplicar. Dar ejemplos de los testing y que errores o bugs se han encontrado, para explicar mejor.

Grupo 8

Aspectos positivos

• Muy bien incluidos los anuncios en la presentación, muy orgánico. Se ve por la estética que la publicidad tiene una clara conexión con la presentación

• Spoony en la DEMO está muy chulo. Además por la DEMO se puede ver que la aplicación es muy intuitiva y sencilla. La estética lo mismo que con la publicidad, que tenga la misma estética permite ver una clara conexión entre ambas partes

• Posible mejora, la demo es un poco larga.

• Spoony cuenta la calidad del código, buen uso de la mascota, no simplemente que esté en la presentación, si no que haya interacciones con ella.

• Buena gestión con los usuarios pilotos, centrándose sobre todo en la categorización y priorización de las respuestas de los usuarios pilotos dando detalles de cuando es alta, baja y media.

Feedback

Su forma de presentar le falta un poco de mejora. Parece que se solape una frase con la otra. Se puede recortar un poco el alcance de lo que cuentas. Eso provoca que la audiencia se salta varias partes. Falta un poco más de metáforas visuales y menos texto. Deberían de intentar el equilibrio entre ambas partes. El killer opener está mucho mas hilado con el restos e la presentación. De los anuncios primero han puesto uno de usuario normal, otro de premium. Mejor unir ambos videos. De esta forma puedes hacer un único video con todo. Pueden hacer un anuncio donde se comenten dichas partes. El de inversores han puesto las cifras, pero no la cita de la institución/fuente. Cuando tienen una cifra que intenten como ponerlo. La población entre 25 y 35 años no saben de donde se saca ese número. Mejor que no descarten la población entre los 35 y 49 años, ya que también puede ser público objetivo y se puede perder. La priorización de los UP es muy bueno, con ejemplos… Ahí se ha empezado a cansar con el texto. El plan de contingencia también es muy bueno. En el análisis de rendimiento no ha entendido nada. El análisis de rendimiento son como problemas o retrospectiva, y es anticlimático, y puede ser el título. No le ha terminado de encajar. MUCHO TEXTO.

Grupo 11

Aspectos positivos

• Muy buen inicio efectivo, y buenos anuncios, divertidos, llaman mucho la atención para que estés atento.

• La interfaz de la aplicación me parece super buena, muy atractiva e intuitiva. Muy buena idea lo de la persona de mediador y lo del paintball.

• Me ha gustado la gráfica de horas / sprint, enseña muy bien como la automatización de tareas les ha ayudado a ajustarse a las horas por entrega recomendadas.

• Muy bien el Hall of Fame y Hall of Shame, muy divertido

• Filmora y ElevenLabs (herramientas IA para anuncios)

Feedback

El killer opener algunas veces infieren un poco demasiado. Hila muy bien los videos con la presentación. Las dos mascotas está n muy bien planteadas y hechas, y se integran mucho en la presentación. El hilo argumental tiene que ir más continuado. Dicen que tienen que estar, en un orden. No tiene por qué ir en ese orden, pueden modificarlo para que siga un hilo. La gráfica de costes, no ponen ni el número de coste ni ingresos, tienen que cambiar la forma en la que se muestran las gráficas. El team building es por parte del feedback positivo. No sabe quien ha ganado en el paintball. Hall of fame está muy bien contado. Ha sobrado demasiado tiempo. Si le quita el incremento ha terminado demasiado pronto.

La idea muy graciosa y muy bien pero hasta q no rompe no ve la intención. El anuncio de cliente muy bien, con el perro, lo unico que no se entiende bien lo que dice el perro, subir audio para que se escuche mejor, bien que se utilice IA pero cambia el acento un poco. La demo muy bien hilada con javi y coco, igual que al final, muy bien hilado desde anuncio y demo y al final, eso es lo que buscan y que cirren el hilo argumental. Ha habdo varios saltos de temas, el orden no esta bien, la demos despues del rendimiento del equipo. Los anuncios, demos del producto primero el qué y luego el cómo. La comparativa de la competencia despues de hablar de numero y cifras y demas, primero el que haceis. Es importante que el hilo argumental vaya continuado. Dicen un orden pero no tiene porque ser ese orden, debemos seguir un hilo conductor y encontrar el mejor orden. La grafica de evolucion del TCO, beneficios perdidas,¿porq poneis eso?, beneficios 20 y perdidas 20, por ejemplo poner 20, 60, -20, -60. Team building cree que todos los grupos deberiamos hacerlo. El hall of fame espectacular, super bien contado, te ha dado tiempo recrearte pero ha sobrado demasiado tiempo.

Grupo 9

Aspectos positivos

• El segundo video es muy gracioso, y le explica muy bien alas personas que venden esquelas como puede mejorar su negocio. Es intuitivo.

• Os felicito por refactorizar el backend, eso ayuda en un futuro a que sea más facil de poder corregir posibles errores en un futuro

• Muy buena cobertura, también os felicito por eso, ya que estar solucionando esos errores es muy pesado y tedioso.

Feedback

Muy bien hecha la presenyación. Ha ido muy bien de tiempo. Les va a ayudar lo que va a necesitar para la siguiente semana. Certifican el fallecimiento? No, lo exigen para poder continuar con el procedimiento. La demo era excesivamente rápida. A lo mejor no tienen que presentar todos los casos de uso, puede que sea menos pero más pausado. Entre zoom y el zoom-out lia mucho. No sabe si está haciendo una acción u otra. Cuando se usa mucho abruma. No tienen por qué poner el login y eso que es innecesario. El de usuarios ya lo vieron el otro día. El de empresa decae un poco en estilo, forma y fondo. El para empresa podrían usar la IA para hacer el video. El story board de la empresa estaba más claro que el video. En que momento han añadido esas características o requisitos? la diferencia no la termina de ver. Cuando aparece ese salto de la parte abierta del product backlog. Hay que aclararlo, y no tiene que haber mucho esfuerzo para aclarar eso.

---

Indicaciones Generales

Tareas Extra y Recuperación de Nota

Van a permitir recuperar la nota del sprint S1 y S2, los documentos a entregar se harán por EV. Tenemos que dejarlos congelados el 24 de abril. Se entregará como parte de world project launcher. No va a estar en el S3. Con un trabajo extra individual se hará una tarea extra. Se Propondrá durante semana santa y feria. Es entre el 25 y el 2. Solo por participar en esas sesiones de los viernes, y con las preguntas se tendrá un 0,5 (0,25 solo por asistir y otro por hacer preguntas). Es un repaso de aspectos interesantes. Para apuntarse a esta actividad podrá ahora una URL, antes del próximo viernes después de feria, 23 de abril

---

Para la Siguiente Semana

Nose pedirá una presentación grande. Se harán dos presentaciones pequeñas. Una que tenga estructura arecida, siendo lo que se va a lanzar el día del lanzamiento. Son 10 min máximo. Otra de 5 min donde se darán detalles más específicos de lo que se ha modificado. Como el márketing, cosas del prooject launch. DOS PRESENTACIONES. Para la presentación debe responder 6 preguntas, de un nuevo producto que se está lanzando.

• ¿De que va el proyecto? Por ejemplo killer opener o anuncio, lo que queramos (1 min como mucho)

• ¿Que hace exáctamente? Por ejemplo una DEMO, enlazada con la historia del inicio. Que sea consistente

• ¿A esto nadie se le ha ocurrido antes? Decir cuales son los factores claves, competencia

• ¿Después de esto quien hay? el equipo

• ¿Esto puede llegar a ser rentable? el negocio, los planes, la forma de vender el producto. Una versión muy alta del modelo de negocio, los costes, ingresos, a corto o medio (Imp las oportunidades que ofrecemos son estas, como por ejemplo un video, contando oportunidades de inversión)

• ¿Qué enlace o QR puede tener para contactar?

Segunda presentación: como es para el primer proyect launch, siendo oriendata a vender el producto, se dedicará a como vamos a hacer el márketing con ejemplos, al modelo de segmentación, cuales son los usuarios potenciales y caracterizarlos (el concepto de persona se puede usar, es una caracterización de un personaje ficticio, pero que parezca realista, donde se incluyan los objetivos, frustraciones…) Como vamos a usar las herramientas de búsqueda (Si buscas un anuncio sobre que palabras claves queremos que se busque el negocio), organizar la campaña de lanzamiento del producto (Como eventos, actividades a realizar para promocionar), que tipo de forma para poder tener el crecimiento de la comunidad inicial. Cuales son los objetivos del comuniti management, los roles, los costes del márketing varias en base a eso, propio comunity manager… Imp los anuncios del inversor, uno para el usuario y otro para el cliente, si estos dos son distintos. Si ya hemos presentado los anuncios. Podemos mejorarlos o podemos hacer uno nuevo, tenemos libertad para definir pero sobre todo echando cuenta a su feedback para ello.

---

Semana 10

---

Grupo 7

Beneficios negativos es una incoherencia. Normalmente los gastos de un equipo son constantes. No ha habido Killer Opener, es importante ensayarlo durante las presentaciones para clavarlo en las sesiones evaluables. Ha habido mucho eco durante los videos. Los altavoces no están sincronizados con el ¿proyector? Importante si presentamos primeros. Demo muy acelerada. La música de fondo despistaba más ayudar. Sin killer opener y con un elevator pitch muy rápido, no ha habido línea argumental durante la presentación. Introducir un poco lo que se va a ver en los vídeos para que no tengan que inferirlo los profesores. Competidores se ha pasado de puntillas. Destacar el diferencial de cada uno. Evitar decir que alguien no es competidor directo. Anuncio de inversores bien, pero los paquetes de inversión son muy pretenciosos, muy difícil encontrar alguien que te de 50k directamente, mejor paquetes más pequeños. Se dan porcentajes muy altos a gente de fuera. 7-10% es lo estándar. Plantear campañas kick starter para permitir a gente de a pie invertir. Hay una plataforma que trocea un producto, para que los fondos distribuyan. Buenas publicaciones en redes sociales según el objetivo. Bien dividir pre lanzamiento, durante lanzamiento y post lanzamiento. Más específico con la planificación de publicaciones. Ej: Lunes: teaser, Martes: cuenta atrás, etc. Falta definir objetivos, nº de impresiones, % de impresiones que se transforman en usuarios. ¿Cómo se reacciona si no se cumplen los objetivos? ¿Cuánto se va a invertir en cada campaña de marketing, y por cada red social? Muy buen branding. En el brandboard falta el peso de la tipografía (light, bold, etc). Hay que cambiar algun contenido de presentacion.

Grupo 8

Primera presentación

Ahora mucho mejor a la hora de presentar, ha presentado infinitamente mejor. Le ayuda a tener transparencias menos sobrecargadas. Donde más atropellado vas es donde hay enumeraciones. Le ha sobrado 3 minutos. Presentación bien, pero cosas mejorables: Que haya un hilo argumental. El killer opener muy bien. El anuncio ha sido increíble. Es otro ejemplo distinto. La DEMO tampoco. Debería haber una coherencia entre todo ello. CONEXIÓN EN TODA LA PRESENTACIÓN. Buenos ejemplos pero desligados. En el anuncio no hay comida infantil, y se habla de comida. Tiene que haberla y problemas con la comida. La DEMO se queda un poco escueta, muy corta con toda las diferencias con los competidores que no han descatado. La DEMO debería tener más peso que los anuncios. No combina la DEMO con las características, que se vea lo que han construido. Que se acuerden de las cifras y no tantos ceros en las gráficas de los costes, para que se vean mejor. Que sean homogéneos con las unidades. No se sabe que hay entre los 6 meses y el año. El video de inversores se queda un poco corto, como modos de inversión, paquetes de inversión… Y el retorno de inversión esperado. Hacer que el negocio con mucho riesgo sea atractivo.

Segunda presentación

Colaboraciones con influencers muy bien hecho. La cosa es si pagar a los influencers o hacer nosotros de influencers. El tiktok muy gracioso, pero pondría a un bb. Y que no haya comida de adolecente. Que concuerde con la temática. La planificación se acerca, pero no se sabe que es lo que va a hacer cada spoony. No se sabe en que red social se hace la publicación. Muchas cosas bien plateadas. Los costes de márketing no se sabe si lo han mencionado antes en el plan de márketing. Que es lo que hacen en cada sitio mejor eso.

Grupo 9

Buen ritmo. En general bien, buena linea. El mensaje inicial con ese collage de imágenes hay demasiadas cosas, muchos guiños, siendo algo serio también. No cumple con el efecto que si cumple con el siguiente video. El orden lo pueden alterar. No pueden ser cosas separadas, pueden combinar los dos si desean. Tienen la potencia de la motiviad en el video. Que la exploten desde el inicio. Lo importante es que el checklist esté. El orden de las preguntas es el adecuado, pero como las responde puede modificarlo si desean. No es tan emotivo como el video. Pueden poner el video primero, y luego el killer opening. La DEMO está bastante bien. La moral del equipo y las horas invertidas eso ya no pega. Están simulando la presentación del día final. Es una etapa donde se vende que todo va genial, no se puede decir que ha ido mal o bien el equipo porque deja mal. La retrospectiva no. La 23 genera problemas, habla de la cantidad cercano al 60.000, pero no ha dicho mucho del caso optimista y pesimista (por ejemplo la cantidad de usuarios para esos casos). Se repite en el video de inversores. En el video de inversores, el rol no deja muy claro al inicio. El porcentaje y el dinero es muy importante. Las he faltado eso (1000 euros con 10 % no es lo mismo que con 1 %). EN las protopersonas cambiar el estado civil, pone trabajando, eso es estado laboral. Revisar muy bien las faltas otrográficas de la presentación. Muy bien el concurso interno que se ha hcho para elegir los anuncios. Posible idea invitar a algo al ganador. Especificar el número de publicaciones de cada red social. Es interesante poder automatizar la revisión de esquelas, es un buen punto para ahorrar el sueldo de alguien que tenga hacerlo de forma manual (a futuro). La plataforma es la responsable de una publicación fraudulenta / maliciosa, no la cuenta que lo sube. Es peligroso que el trabajo de revisarlo todo sea manual. La IA también da problemas, falsas alarmas por ejemplo. La IA puede ayudar a generar los textos de esquelas, es interesante integrarla en la aplicación (a futuro). Bien en número de publicaciones.

Grupo 10

Pablo, muy bien como presenta, buen killer opening. El anuncio le ha encantado, Tiene que mejorar el timing, pero bien. Metería también de lo que ha pasado otrad e las funcionalidades que tiene el tema de las notificaciones que le quedan X días, se puede incluir en la demo. El video de cliente un detallito. El: esto es como… es una forma de arrancar la idea. El inicio ha conseguido mucho mejor efecto, y le ha gustado más. Hemos alcanzado un buen punto en el mensaje. Equí ya no hay que hacer retrospectiva. No hay que hablar del pequeño equipo de desarrollo. Para esos comentarios ya mas bien es del PPL. En la 15 habla del estado del proyecto. Si se quiere hacer es en el PPL. Nos e va a poner el en WPL. Si se ha ido por encima se verán en los costes que serán mayores. En la 17 al hablar del optimista y del pesimista es bueno poner esos porcentajes. Es mejor ponerlo en el siguiente. En la 16 mucha infor y demasiados conceptos. Simplificar el mensaje que damos ahí. En esas curvas, donde en la semana 5 se unen optimista y … no se ve claramente. Es mejor poner tres gráficas con el flujo de cajas que en vd solaparlos. En el WPL PONDRÍA LA ESPERADA, LA QUE PRETENDE, y así lo deja claro. El video de inversores le han faltado el modelo de negocio, de donde vienen los ingresos y el negocio. Habla de los costes. Que le hable de los medios para obtene ingresos. y lo de 1K = 1.000 euros quitarlo, ya se entiende. Habla del concepto del aburrimiento crónico, es gracioso, pero no se puede dar ninguna evidencia de una fuente que, el estudio no se ve, con la cita a la fuente. Eso no lo podría ahí, ya que no se ve, mejor que se ponga a la derecha superpuesto una artículo o algo así para que se vea. Diversos estudios tampoco no si se muestra 1. FALTAN LAS OPCIONES DE INVERSIÓN. Lo de los otros grupos aplica. 200.000 se habla, pero no de porcentajes, y no se sabe si es mucho o poco.

Le ha gustado como se han definido los KIP’s, Y ESO ESTÁ GENIAL, PERO LE FALTAN UMBRALES/ números. Al final necesitan definir objetivos, no se sabe si es mucho o poco. Igual que con el plan de riesgos, sino queda en algo genérico. Linkedin es curioso que sea. Ese contendio no lo va a ver en una red profesional, es mejor no hacerlo en una red socializada. Al final es mejor plantear el objetivo y los PLACE TO BE. La mayoría de nosotros creamos perfiles, las dotamos de contenido, y creamos crecimiento orgánico y viralidad. El lugar es para los inversores, ver que es para esa población, y hacer esa conexión. Si no queda todo muy deselnazao. Cual es el objetivo, a quien va dirigido, las redes y como lo vamos a hacer, los KPI’s… los planes de publicidad. Esas protopersonas hay que pensar a que tipo de nicho van. Cualquier publicación a los inversores se puede publicar a las publicaciones. Que se planteen herramientas dashboard está genial. Ningún grupo hasta el momento ha descartado MASS-MEDIA. Podríamos hacer publicidades en streaming por ejemplo. Netflix también tiene anuncios por ejemplo.

Pablo muy buen como siempre, presentas muy bien, killer opening myy efectivo. El anuncio me ha encantado. Tambien le ha gustado la demo con sorpresín hablando con él, muy bien. Tienes que mejorar timing entre los dos porque os cortais. Como hablas de lo que ha pasado ya, podemos mostrar lo de la notificación en el video. Video de cliente un detalle: esto es como un sitio, explicar un poco mas el producto. Hemos alcanzando un buen punto en el mensaje. No tenemos que hacer retrospectiva, no hablar de pequeño equipo de desarrollo arreglando los bug, esa parte en el ppl si la podriamos hacer uhn pequeño resumen los arreglos, en el wpl no. En la 15 hablamos de estado del proyecto actual pero no, esto en el ppl. En la 17, al hablar de porcentajes mejor ponerlos. Demasiada info en la 16, no saben bien donde va la negra, mejor 3 graficas donde se ve el flujo de caja. Para el wpl solo pondria la estimacion esperada, puedes poner margen de error pero se ve mas claro. Le ha faltado el modelo de negocio, de donde viene el dinero, como sacamos esos ingresos. Inversores: habla del concepto del aburrimiento cronico es gracioso el concepto pero lo malo es que no se ve el articulo, eso lo pondria que se viese mas porque no se ve y asi no funciona. Diversos estudios?Solo sale uno. Mola pero que se vea mejor. No damos opciones al inversor, hablamos de 200k pero no se habla de porcentajes , no se sabe si es mucho o poco. Siguiente presentacion: le ha encantado como hemos definido los KPIs, le parece que esta super bien pero falta numero, metricas (el limite, donde queremos llegar). Necesitamos definir objetivos, metricas es mucho o poco, simplemente decimos lo que vamos a medir. Queda algo muy generico. Le ha llamado la atencion que pongamos linkedin porq como vamos a hacer publicidad en esas redes sociales, a quien nos vamos a dirigir en esa red social, esa red social es mas profesional, no va a buscar ese tipo de contenido en esa red social, no hace falta hacer una red social forzada. Al final tenemos que definir los objetivos, donde tenemos que estar y para que. Si el lugar donde vamos a estar es paralelos inversores, debemos saber en que red social nos tenemos que mover para ello. Eso que presentamos en las protopersonas, debemos tener una trazabilidad del principio al final. Van poner pildoras teóricas para esto. Hay que pensar que de nuestra publicidad a quien va, linkedin alfinal es util para los inversores, se puede publicar ahi. Metricool? bien, hemos hecho pruebas? no pero hemos visto que nos puede ofrecer.

Ningun grupo hemos puesto nada sobre algun medio masivo en donde tendriamos sentido publicitarnos. Hay que conocer el publico objetivo.

Grupo 11

Parte técnica resuelta, porque da problemas. Cosas como en la demo no se veía y cosas así. Para el directo serán muy estrictos. La historia inicial no es realista. No tiene que ver con el producto en sí. Puede ser bueno si hay soporte visual. Que se fijen en el anuncio del perro curro. Puede hilar el inicio con la demo/anuncio por ejemplo con coco (el perro). El icono del cursor si lo cambia por una patita parece que el lo está haciendo. La demo estaba un poco alto la música. El tema de la ludificación, donde engancha al usuario a que ustilicen pawtel con puntos, como booking. Se debería hacer algúna estrategia como esa para que la gente no se vaya de pawtel. El video de inversores empiezan con “Hay 30.000.000 de mascotas” y que el audio y el video haya una disonancia descuadra. Hay que ser consistente. El video está muy bien el de inversores. Es muy específico las protopersonas, debe ser más genérico. Que se tenga clara la diferencia entre el problema y la solución. Las búsquedas, las fecha no se ven bien. Pensaba que era cada semana del año. La estacionalidad es lo más importante, y si la hay, en los datos del negocio económicos debe reflejarse. ANÁLISIS DE ESTACIONALIDAD, y que se reflejen en los costes. Ponerlo antes de los costes es importante. Es importante indicar también DONDE SE ESTÑA HACIENDO, si es nivel mundial o nivel de España. Indicarlo. La estacionalidad TIENE QUE ESTAR, ES MUY BUENA ESTE ESTUDIO. El uso de la IA, utilizaban chatGPT “Al igual que otras IAS”, que las indiquen y muestren. Para la semana que viene es un cartel de nuestro negocio, promocionando el WPL para que vengan a las presentación. Las proporciones y tal está en la web.

---

Indicaciones Generales

Notas

Startups: como esos modelos incrementan. Para hacer que esos startups llegena los inversores. Debe de estar con una breve información y tal. Para acceder a comprar startups. Es para ver información de esta info del mercado. El concurso de las ideas empresariales de la US. Que participen todos los grupos. La de inicial es el modelo de negocio en modelo kanva. El último día es EL LUNES 18.

De semana santa y de feria no son lectivas, como se han hecho? No se han contabilizado. Lo único es contabilizar horas que no han echado horas. Si han hecho de más serían con horas extras. Esas horas extras hay que pagarlas más caras. La feria y semana santa no son lectivas, asi que no se cuentan horas. La última pildora teórica es esta tarde noche.

---

Para la Siguiente Semana

Lo mismo de hoy, no van a ampliar nada nuevo. Mejorar todo lo dicho. Pasaremos de un plan de márketing a uno más de en ejecución. Esa evolución la quieren ver en la presentación. Hay que revisar el contenido con el contenido nuevo que surja. Es el último ensayo antes del WPL antes de tener feedback. Tenemos la opción de ensayar en el salón de actos el día de antes. Para probar como se ve al enchufar el cañón. PARA EL PPL NUEVO DESPLIEGUE si se han cambiado cosas. La semana después de feria, en la retrospectiva se hará una presentación con lo que han hecho cada estudiante en la presentación. Definiremos los turnos quien va antes y quien después. El grupo completo dirá lo que ha hecho. Después del PPL deberán continuar contactando con estos para ver que han estado haciendo.

---

Semana 11

---

Aquí tienes el feedback y anotaciones reorganizadas por grupo en formato Markdown (.md) y con explicaciones más claras y ordenadas. He añadido subtítulos y separado el feedback positivo del mejorable, para que sea fácil de leer y usar como guía de mejora.

Grupo 11

Feedback Positivo

• Inicio muy efectivo, usaron la aplicación de Caronte inteligentemente en el killer opener.
• Colaboración con otro grupo: bien planteada, aporta profesionalismo.
• Anuncio realizado con IA, de calidad profesional.
• Carteles publicitarios muy bonitos y bien ubicados por la universidad, buena estética y buena cantidad de información.
• Uso de IA en marketing para obtener ideas: gran acierto.
• Análisis de KPI’s en redes sociales: muy valorado.
• Uso de branding en el killer opener: recurso potente.

Aspectos a Mejorar

Hubo un problema técnico repetido que también ocurrió la semana pasada; es importante evitarlo en el WPL. Se sugiere usar, en el peor de los casos, el altavoz del PC. Hablar sobre el equipo de desarrollo no aporta valor al inversor en el momento actual de la presentación, por lo que sería mejor omitirlo o plantearlo de forma más general. Repetir nombres de personas no queda bien.

Se recomienda evitar términos técnicos como CAPEX y OPEX; en su lugar, usar expresiones más claras y accesibles para cualquier audiencia. También es importante evitar mostrar texto mientras se habla, ya que el público no puede leer y escuchar a la vez.

Se observó que la presentación quedó detenida esperando que apareciera un texto, lo cual rompió el ritmo. Además, en el anuncio se mostró la diapositiva número 17, lo cual no tiene sentido en un anuncio público. Sería mejor eliminar los números de las transparencias en este tipo de contenidos.

---

Grupo 7

Feedback Positivo

• Excelente killer opener: buena combinación con audio y recurso del apagón.
• Anuncio de TikTok muy atractivo.
• Demo con estilo TikTok: ideal para redes sociales.
• Mapa del equipo en diapositiva: excelente recurso (idea a copiar).
• Referencia a Shark Tank renombrado como “Pescaito Tank”: creativo.
• Presentación bien vestida y profesional.
• Amplio rango de inversión: aumenta posibilidades de captar inversores.
• Bien explicado cómo optimizarán el SEO.
• Brandboard muy logrado en la penúltima diapositiva.

Aspectos a Mejorar

Se valoró la interacción, aunque se recuerda que debe estar alineada con el contexto del salón de actos para el WPL. El anuncio dirigido a clientes gustó, pero la última frase con eco resultó extraña y distrajo.

La historia del "killer opener" no se conectó adecuadamente con la demo, lo cual rompió el hilo argumental. Se recomienda mantener un trabajo autocontenido y con coherencia narrativa. La tabla de competidores necesita una reorganización: primero deben explicarse las características de la app, y después mostrar cómo se comparan los competidores.

La explicación sobre los ingresos fue algo confusa, ya que no se clarificó qué representan cifras como los 40.000€ mencionados: ¿es beneficio?, ¿en qué periodo? También falta claridad sobre el precio por acción y lo que se está comprando exactamente.

Se sugiere explicar mejor la rentabilidad y separar claramente la información financiera. Algunas palabras clave propuestas son poco realistas para búsquedas (“mapas colaborativos” o similares). Se recomienda enfocar las keywords en problemas reales que la gente busca (“Estoy aburrido”, “No sé qué hacer”). Muy bien definido el plan de acción, que relaciona problema con solución.

---

Grupo 10

Aspectos a Mejorar

El video de redes sociales tenía una iluminación deficiente. Se recomienda invertir en un buen entorno de grabación para evitar horas de edición. El audio agudo del inicio (“Sorpresín”) no se entendió bien. En la demo, algunas partes no eran visibles, como la reserva en el calendario.

En la diapositiva 16, se leyó el contenido de derecha a izquierda, y faltó justificar la exclusión de algunas categorías. Esto debería explicarse, incluso dentro de la demo. En la parte sobre acuerdos con empresas, faltó detallar la comisión que se espera obtener y la lógica detrás del descuento del 5%.

El video de inversores se quedó congelado en un momento. También se leyeron las transparencias directamente, sin resumir o adaptar el contenido, lo cual resulta poco dinámico. Se recomienda hablar del precio por acción en vez del porcentaje de participación, e incluir detalles sobre incentivos para obtener reviews (por ejemplo, descuentos).

Las keywords son demasiado genéricas (“Estoy aburrido”); sería más útil plantearlas como problemas específicos. La propuesta sobre eventos grupales entre desconocidos ha gustado y puede aportar un valor diferencial.

---

Grupo 8

Feedback Positivo

• Canción personalizada: original y distintiva.
• Gráfica de costes, ingresos y beneficios clara, con eje temporal (1 y 2 años).
• Estética cuidada y presentación visualmente consistente.
• Colaboración con influencers (padres y madres): buena idea.
• Planificación de publicaciones bien pensada y explicada.

Aspectos a Mejorar

Aunque el anuncio ya incluye comida (lo cual es positivo), la demo parece que no tiene audio, lo cual genera confusión por contraste con el anuncio, que sí lo tiene y con buena calidad. En la parte de ingresos, el factor tiempo es fundamental y debe tratarse con mayor claridad.

La segmentación del público objetivo debería presentarse de forma más compacta, no en partes. Se echa en falta información sobre el babyboard o el progreso por fases. El marketing necesita aterrizarse más en casos concretos y aplicados. Es importante que se entienda claramente para qué se pide dinero.

---

Grupo 9

Feedback Positivo

• Colocar el killer opener al inicio: acierto.
• Demo explicada paso a paso, muy clara.
• Valor añadido de Caronte frente a competidores: bien expuesto.
• Monetización bien visualizada: CAPEX y OPEX bien diferenciados.
• Certificación y colaboración con Pawtel: valor extra.
• Cartel hecho a mano: muy estético y destacable.
• Hilo argumental y ritmo: muy buenos.
• Tono más serio y menos paródico: bien equilibrado para inversores.

Aspectos a Mejorar

Se considera un muy buen ejemplo de proyecto. Muller incluso aplaudió la presentación. El hilo argumental tuvo buen ritmo, y aunque fue uno de los proyectos más complejos de presentar, fue el mejor ejecutado. Sin embargo, el volumen del sonido estaba demasiado alto, compitiendo con la música.

Llamaron la atención términos como “Past Post” o “Life Will”. El ritmo narrativo fue interesante y consiguió destacar. No se abusó de la parodia, algo que se agradece por el tono más profesional. Sin embargo, el video para inversores debe ser más neutro, no completamente serio pero tampoco cómico.

Para el último día, se recomienda evitar cameos confusos o situaciones en las que no quede claro el orden. El proyecto no requiere tantos elementos visuales; mejor centrarse en una sola dirección clara sin dispersarse.

---

Anotaciones Finales

• Usuarios piloto → revisión en 4 entregas.

• La semana siguiente será de evaluación retrospectiva.

• Habrá una sesión individual (1 a 1) de máx. 5 minutos por grupo para evaluar reparto de puntuaciones y rendimiento.

• Evaluación grupal, con posibilidad de normalización si hay grandes diferencias entre miembros.

• Presentación grupal final de 5 minutos sobre:

  • Qué ha ido bien.
  • Qué ha fallado.
  • Qué soluciones se han dado.
  • Nuestra visión del proyecto.

Preparación para el WPL

• Fecha del evento: 23 de mayo (obligatorio turno tarde, opción mañana).

• Hay que estar antes de las 15:30.

• Posibilidad de ensayo el 22 de mayo de 13:30 a 16:30.

• Duración: 10 minutos, incluyendo parte de marketing.

• Crear un slide de anuncio del proyecto para colocar en la ESTII (antes del 13 de mayo).

• Habrá streaming del evento (se grabará).

• Se entregarán premios a:

  • Mejor presentación.
  • Mejor demo.
  • Mejor killer opener.
  • (Otros...).

• Evaluación también con Wooclap.

---